Package Manager Repos

[sindbad]

I was under the impression that GTK ran under X in Mac?

Indeed, if GTK doesn't run on a Mac, I'd like to know what OpenOffice 2.4 (stable version, not the alpha junk) is using for its interface.

It runs, but it's sub-par. In the same way that wxWidgets runs under KDE, but looks and behaves alien. (disregarding hacks like gtk-qt)

 

[yosh64]

hey

Well I haven't read no way near all the posts in this thread, but anyhows I think libs should also be handled by the package manager.

Firstly, what is stopping people from making their SDCard or whatever a local repository? If you want you can still download packages onto ya PC and then all ya would do is copy them into ya local repo and install with the package manager.

Anyhows I use http://www.archlinux.org on PC myself, and they have a nice binary package system called pacman, so maybe take a look at this.

But yea, why bother with static linking? actually I can think of one advantage, that is if a bug is introduced to a lib then it won't affect ya software, but ya miss out on bug fixes also until the developer of the software updates it, hehe. Basically in this way I think it might be a nice idea to just do static linking, whether it's enforced on the developer todo so is another story. But yea, from what I understand is that when things are statically linked then there will be less hassle in keeping packages and everything compatible, especially when there are design or major changes to a lib, all your old software abandond by the developers will still function.

Actually, one thing I wonder about is non linux based apps? will the package manager handle these?

edit
I've just been reading back a few pages and seem to agree with alot of things Squidge has said, so maybe a strait up package manager isn't the best option. But one thing I like about a package manager is that you can easily search for apps, and install just like that, the other thing I like about package managers is that they keep everything organised for you, and so ya don't have to worry about your libs and dependencies. Linux is kinda a pain without a package manager, I mean apps depend on SOOO many libs it's not funny, and to manually go through and find each lib and figure out how to install each is just a crazy time. But yea, I imagine things will be very different for linux on the pandora, so I dunno.

I'm not sure how things are done on the gp2x, so maybe there is something to be learnt about how things are done with it.

another
I just thought of a cool reason for some sorta package manager, that is that you can easily install new progs on the go without being near your PC , saves you manually going through and finding them.

Ohh, and yeah it's kinda a pain for the developers to go through the workflow of actually producing the packages and such, but it actually enforces them to write a nice bit of info about the prog , assuming it's anything like pacman on archlinux.

Anyhows I think this is a tough decision and all options need to be weighted.

and another
If there is to be support for general dynamic linking then a package manager becomes quite essential, if programs may depend on lots and lots of libs then it's kinda harsh to expect the users to peice everything together. But then again, on a small scale this might not be such a big issue. On this note I think static linking may very well be the better option, but doing so is removing a big part of what linux has to offer.

cyas

 

[DarkScale]

:blink: I don't understand any of this .
Can someone give me a quick, patronizing explination?

 

[Chip]

:blink: I don't understand any of this .
Can someone give me a quick, patronizing explination?

There's a patronizing explanation a bit farther back in the thread:

A Package Manager is a program that goes out and installs programs for you. It will install a program and any other programs that the one you want needs, automagically and easily. APT, Portage, and YUM refer to three of the most commonly used package management systems in Linux distributions today. APT being lighter weight, Portage being optimized, YUM being powerful yet somewhat bulky (theres not much that YUM can do anymore that APT cannot do faster).

"As long as it has a GUI I'm fine" would likely be your choice. You don't care what backend (the behind-the-scenes people) is used as long as it is practical and EASY to use. GUI stands for Graphical User Interface. It basically means you have a little window that shows up on the screen that makes a program easier to operate by giving the user visual choices rather than typing commands into a command line. You can search "SNES emulator" or "Arcade game" and it would find games based upon your search.

So the question you need to ask is: "Would I like a program to go out and fetch programs (emulators, media players, and applications) for me, or would I like to go out and find them myself?". The end result is the same, you get your emulators / games / media players. The difference is how you get them.

 

[DarkScale]

I read that but am still confused.
Is it kind of like a search engine that searches through all the pandora related software? Will it be kind of like the current GP2X file archive but with all the library sharing that people say will save space?

Thanks for being patient with me

 

[Orkie]

I think people are being incredibly dense in this thread. It uses the Linux kernel, it will probably use a lot of libraries often found on standard Linux distros however neither of those mean it has to function in any way like a PC installation. Since when have you had to play around with dependencies on a game machine? A base set of standard shared libs with the option to include further shared/static libs in your game is the best option.

The fact of the matter is, nobody is going to force people to use a package manager to install even the most basic of things (as a lot of new members who are self proclaimed Linux gurus here seem to insist is essential) which is lucky because package managers don't deal with removable media that well - they are designed for filesystems which don't change a lot.

 

[sindbad]

The package manager would manage the 256mb of internal nand. Removable media is tricky (still doable, but requires some careful planning) and risky experiments are not a good for a new system.

It's hard to install and update software with complex dependencies without one.

 

[_VWV_]

Since when have you had to play around with dependencies on a game machine?

The andora1: is not only a gaming machine. Some one might want to use it as a powerful handheld/UMPC - i.e. for general purposes + some multimedia. Everybody understand the phrase "for general purposes" a bit differently, so that it would be nice to have a repo with some ready to install staff.

But seriously, do you think we need to stay cutting edge with the Linux kernel? I'm thinking of the GP2X kernel, and how many times people have complained about kernel version shipped with it that has never changed, and how long its going to take for a version of the kernel to change in such a way that it breaks compat with binaries. 3 years and the Pandora will be pretty much obsolete anyway.

Sorry to brake into your discussion, but i think we shouldn't limit the life of the andora1: . I've been using my PIII Katmai as an internet-office-multimedia station for 9 years already and it still works. I really don't think that if the andora1: is capable of all that now it wont be capable of that in 3 years. But I can easily imagine that a 2.8 kernel will appear in 3 years time. So if it's possible.. can you at least make such an option like kernel upgrade.. I thought that it's impossible to extract all the specific staff (the drivers) from the TI's kernel and incorporate it into a fresh vanilla kernel.. but if it's possible, at least in theory, we should consider this as an option..I think.

 

[Orkie]

The package manager would manage the 256mb of internal nand. Removable media is tricky (still doable, but requires some careful planning) and risky experiments are not a good for a new system.

It's hard to install and update software with complex dependencies without one.

Yes, a traditional package manager is fine for the NAND - that is exactly what they are designed for, system updates. The point of a combination of static and dynamic linking is that there are no dependencies that have to be installed.

The andora1: is not only a gaming machine. Some one might want to use it as a powerful handheld/UMPC - i.e. for general purposes + some multimedia. Everybody understand the phrase "for general purposes" a bit differently, so that it would be nice to have a repo with some ready to install staff.

They will probably want a totally different firmware installed on SD for that anyway, so it is irrelevant.

 

[AireTamStorm]

The andora1: is not only a gaming machine. Some one might want to use it as a powerful handheld/UMPC - i.e. for general purposes + some multimedia. Everybody understand the phrase "for general purposes" a bit differently, so that it would be nice to have a repo with some ready to install staff.

They will probably want a totally different firmware installed on SD for that anyway, so it is irrelevant.


Dividing the community in half is the last thing we need. One firmware, multiple purposes. This is Linux we're working with here- thats perfectly doable. Ultimately it boils down to the application. Games, maybe statically linked. Everything else (all libs on NAND, along with window managers and non-gaming apps SHOULD BE dynamically linked, and update-able individually. This avoids OS bloat, keeps us up to date, and lets the game programmers not worry about dependencies. Can we come to a consensus on this?

100% Static is evil, 100% Dynamic is a pain. There is a middle ground here!

 

[sindbad]

Mostly. However, as a technical detail, static linking is bad even for libs that are supposed to be distributed with a specific app. If for example two instances of that app were to be started, the libraries linked statically to it would be loaded twice, uselessly eating ram.

 

[Squidge]

I only see games and emu's being statically linked, and your unlikely to be running two emulators or two games at a time.

 

[sindbad]

I only see games and emu's being statically linked, and your unlikely to be running two emulators or two games at a time.
Fair enough.

I keep thinking on how to manage the package manager db gracefully for when the nand gets full and you want to install a package (on the sd naturally).

 

[cools]

I love debian, but if debian is going to be used PLEASE kick it off as a proper architecture port so that debian "proper" repo's are used.

Masses more bandwidth available, patches to packages make it into other systems and vice versa.

And well, an official Debian handheld? The demand would be huge.

 

[Karel Jansens]

People, whatever you do, first take a good look at the repository system Nokia has set up for its Itablets.

... And stay lightyears away from it. I'd even go as far as stating you should do the exact opposite of the Maemo downloads system, because it is indeed one giant f*ckup.

 

[Hooka]

sindbad: you would only have the db for the nand stuff on the nand, have db files on the sd for the sd contents would be best imo (once again, this is all pretty much ficticious...)

Also, is their a way to explicitly tell the compiler that certain libs will be static, while others are dynamic... I thought it was an all or none type deal...

 

[sindbad]

sindbad: you would only have the db for the nand stuff on the nand, have db files on the sd for the sd contents would be best imo (once again, this is all pretty much ficticious...)
Yes, separated databases. But a graceful way to handle corrupt or missing databases, screwed up or non existant file attributes and other things like that. APT is very flexible so it should be possible, but I don't have the time for a proof of concept.

 

[Javacat]

^ Further to hookas question (and excuse my ignorance), does a lib need to be built into a binary to be static and placed in a specific location for it to work dynamically?
If an application used a somewhat uncommon lib for some of its functionality, would it be enough to just place the lib files in the same directory as the application for it to be usable? If another application turned up that used the same uncommon lib and the user so wished, would they be able to move the lib to somewhere then delete the duplicate versions included with the apps, so that they are all using the same one?

 

[Hooka]

Actually, statically linking embeds the library into the executable, the binary is bigger is all... (As far as I know anyways)

I do agree that in general, statically linking for oddball libs will probably be the best choice...

 

[Squidge]

As far as I'm aware, when your static link, only the used routines are copied from the library, rather than the entire library.