GP2X Package Management


ps_

Still Fresh
Joined
Dec 5, 2005
Messages
22
Age
36
Location
Germany
Website
ha-boerse.net
Just an idea, since the gp2x is all linux, how about running a package manager on it ?

Like, what about using ipkg (google for it, something like apt-get only smaller) for software installation, simular to the way the Sharp Zaurus does ?
It would make software installation/managing libraries etc. easier.

Also, maybe we could get opie ( http://opie.handhelds.org ) or gpe running, and use the software packages already made for the zaurus...
 
ps_ posted on Dec 18 2005 at 08:18 PM said:
Just an idea, since the gp2x is all linux, how about running a package manager on it ?

Like, what about using ipkg (google for it, something like apt-get only smaller) for software installation, simular to the way the Sharp Zaurus does ?
It would make software installation/managing libraries etc. easier.

Also, maybe we could get opie ( http://opie.handhelds.org ) or gpe running, and use the software packages already made for the zaurus...
but there is no internet connectivity in the gp2x...
 
Last edited by a moderator:
you could install the packages from the sd card, or via usb from your pc, the sharp Zaurus doesn't have networking by default either and the package manager still is pretty usefull ...
 
Transfer them to SD card and then use the package manager to update it.

Wow, that was SO hard to figure out[/sarcasm]
 
God Ginrai posted on Dec 18 2005 at 09:10 PM said:
Transfer them to SD card and then use the package manager to update it.

Wow, that was SO hard to figure out[/sarcasm]
so whats the use of that, then its still alot of work, sheez...
 
Last edited by a moderator:
aapje89 posted on Dec 18 2005 at 11:26 PM said:
so whats the use of that, then its still alot of work, sheez...

You only copy a _single_ file on you gp2x, and get automagick checking for installed libs (sdl, libwhatever) => no need for all the static linking anymore

Also, if installation is done via pc (that is, you install the packages directly off the internet, over the usb link onto your device), you have all the advantages such a system has if it's connected to the net, like automated update, get all your emu's up-to-date with one click, see everything new on a local interface like the one "synaptic" has (gui for apt-get on linux)

I see quite a lot of advantages there...
 
Last edited by a moderator:
ps_ posted on Dec 18 2005 at 09:38 PM said:
aapje89 posted on Dec 18 2005 at 11:26 PM said:
so whats the use of that, then its still alot of work, sheez...

You only copy a _single_ file on you gp2x, and get automagick checking for installed libs (sdl, libwhatever) => no need for all the static linking anymore

Also, if installation is done via pc (that is, you install the packages directly off the internet, over the usb link onto your device), you have all the advantages such a system has if it's connected to the net, like automated update, get all your emu's up-to-date with one click, see everything new on a local interface like the one "synaptic" has (gui for apt-get on linux)

I see quite a lot of advantages there...
I see what you mean, but the problem is that a lot of people cant get the gp2x connect to their pc using the usb cable.
But if it will work, it would indeed be very nice (I must say I like apt-get, its so easy :D).
 
Last edited by a moderator:
It would be nice for dev's to be able to release games as tar.gz packages.

Might I suggest Slackware's PkgTool (installpkg etc.) Very handy utility. Basically 1 button install of packages. No GUI Frontend (except the ncurses pkgtool binary) as long as ncurses is installed I don't see any probs with PkgTool being used for package management.

NOTE: I am biased in my opinions of package management systems, atp-get is not very smooth in my opinion and RPM is bloated... ideally Gentoo's emerge is the best (but this is not possible on GP2X of course)

Anyways, being a person interested in dev, I can see many benefits of a pkg tool on GP2X... would be nice to have the user install the game I make in one click, no hassles with dependancies or resources.
 
emegere and freeBSD 'ports' are good; all the others are worse than useless most of the time .. especially ROM. Beutiful how Redhat has basicly trained everyone that a reinstall is how you upgrade from one version/dist to another. Shameful.

jeff
 
I had a big rant that I was going to put here, but no one would have read it anyway. The point I was going to make, though, was that for upgrading from one version of an app or lib to another, the ports tree and portupgrade can fuck a dog's ass. The day that portupgrade -r handles a large upgrade anywhere near as well (read: doesn't fuck up on me all the time) as apt-get upgrade, I will be a very happy man. But that might just be the anger talking, the anger of waiting two days for portupgrade to finish upgrading glib and everything that depends on it just so I can install Firefox 1.5 on my laptop. I'm still waiting, by the way. <_<
 
I can see that it might be useful for libraries and such but since most games,emus,etc. are installed on the SD card I really don't see the point. Now a utility or standard to install/update programs would be great. And if a apt-get like program is the answer to part of that query then great.

well thats my two cents. :)
 
Apt-get works really in Ubuntu when all you use is the default repositories – so I wouldn’t see why it would be such a bad thing on the gp2x. However, with that said emerge is still far superior simply because of it’s reverse dependencies, o how I love emerge --depclean. Before anybody even so much as thinks it, you *can* use precompiled binaries with emerge. However since we don’t have network connectivity the Slackware way of doing it seems like a pretty good option. In the long run thou, it seems to me that it makes more sense to fix the network problem, then use emerge.
 
Well, without network connectivity, maybe one could write a command to dump the NAND filesystem to an SD card, and then the PC could update the files, then the updates get applied back to the NAND. Opens up more options for a usable update interface (maybe gtk or qt for windows + linux + mac compatability). It would be cool if it used a command line backend for the actual operations though.

Another option is installing things to the SD card as well - this would let the software check for required libraries when someone wants an emulator, etc, and give the option of installing something to the SD instead of NAND and vice versa (space permitting, and making sure system libraries are on the NAND).

Sounds relatively simple in theory, but package management is pretty hard to get right. One problem I can think of offhand is that FAT32 doesn't allow for symlinks, so libraries could be a pain unless the names (somelib.so.2 instead of somelib.so.2.5.12) are standardized on, or the libraries are all virtually located on the NAND, but could symlink back to the SD card. That might be a better way, as it wouldn't require any hacking to the load paths to get them to be found. But there could still be other packages that use symlinks, and I don't know if there's a good solution for that without modifying the packages, or patching linux to treat .lnk files as symlinks (I think I remember a patch for that existing).
 
Package systems are very hard to get right, but I don't know why they blow it so bad most of the time ;) The one thats worked bet for me has always been FreeBSD ports .. never a problem yet, but RPM's tend to be unusable or correupt their central database. ie: Generally they complain about depends too much so refuse to install, and if an RPM package upgrade occurs, it kills the machine.

apt-get is almost not bad, except theres so many cheap hacks in the system that few know how it works well enough.. and the cheap hacks fall apart. ie: This business with 'virtual' systems, so you can say X11 is a 'window system', or apache is 'an http'.. that way a package can depend on 'some' http to be present, but not care which one you use. Well and good, except when you uninstall some of these packages, it'll remove all depends.. like 'http' and 'window system', so suddenly you lose X11 and apache when upgrading something. Wtf :p

If someone kept tight control over an apt-get package system for 2x, it could work fine; just a simple GUI for 'unpack' and 'remove' on the 2x would be all you need perhaps.

jeff
 
I think the important thing is we need something, the current setup is all well and good until libs get involved.
 
Personally I can see Slackware's pkgtool working fine on the GP2X. Ideally all developers would be releasing statically linked binaries. So packages would not have to rely on dependancies. At least with a custom pkgtool setup (or even custom installer script) developers could develop a standard i.e. games go on /Games, apps go in /Apps etc.

Perhaps if someone can provide a list of avaliable binaries on the GP2X system a small installation system can be made from shell scripts. After that it is just a matter of working out a standard for applications and asking developers to comply, which I don't think would be too hard. Even if developers do want to release dynamicly linked binaries we could setup a /Lib directory just for them and developers can make sure everything is linked against that path.

Just some thoughts. Really someone needs to take initiative and spearhead the project to get it started. I currently have too much on my place as it is (GP2niX and the GP2X-Linux-Toolchain) Perhaps once this is complete I can chip in and help out some. But I really do want to get some dev done on one of my game projects soon.

EDIT: I just had a thought, do you intend there to be a package database/list? If so how would that work if users have their programs spread out over more than one SD card! Just a though!
 
The quicker we lose Linux on the GP2X, the easier everyone's life will be. If you are a game developer for the GP2X and you are serious about it, you will compile statically linked applications with no dependencies on installed libraries. It's the only way to be sure.
 
Just want to note that I have ipkg working using an OpenEmbedded build environment. See my other thread for details or the Wiki, where I have described how to set this up.
 
Back
Top