Building ipkg\'s

[zxerx]

Admittedly, I\'ve only been playing with pdaXrom for less than a week, but I\'m already convinced this the the rom for me. There are a couple of thing bugging me though, and one is the way the ipk files on the pdaXrom feed are packaged up.

I\'m assuming the developers of pdaXrom are lurking so first let me say this is the most brilliant advance in \"*nix in a pocket\" I could have ever imagined even less than a year ago.

My concern is that we are dealing with a hardware platform with specific flash memory limitations. I chose a root partition of 50Mb as advised in the install instructions, and it took me about 8 minutes before I ran out of room when installing packages.

So, what I\'m suggesting is that all packages that are deemed \"essential\" be installed in flash to /usr, while all \"extra\" packages be installed to /usr/local which can reside on a CF or SD/MMF card. Someone with a lot more knowledge than me will have to decide what qualifies as \"essential\" or \"extra\".

And then there are library dependencies... one simple example is the gqview package which includes libpng.so.3 - this should really be in its own package of course.

I\'m sure the pdaXrom team are well aware of the issues involved, but I thought I\'d vent my opinion anyway.

[ScottYelich]

I believe ipk  is just a \"tar\" with relative paths..  ie: the paths don\'t start with /

ie: you can untar in /, /usr/local, /mnt/cf  etc.

the package managers have switches to select where to untar.

For instance, do you have firefox installed?  it takes a LOT of space just to install!
let alone what it takes AFTER it is installed.  Solution?  when I flashed the pdaxrom,
I installed firefox *first* thing ... to my \"sd\" card.  Now, whenever I reflash or remount
the sd, I just ipkg-link /mnt/card etc... and firefox (and gimp, etc) and other programs
are \"installed\" quickly.  

I also ran out of room on my / ... but I think I moved /usr/local to /home/local and then
linked the old to the new path.  That seemed to help a lot.

Scott

[amrein]

I heard about a FreeBSD solution that permits to merge directories content.

For exemple: files from /usr/bin  + /mnt/cf/usr/bin  + /mnt/sd/usr/bin are all listed and accessible from /usr/bin.
No link. No specific configuration. If you unmount the CF, its content in no more listed in /usr/bin /usr/etc , ....

I can\'t see a best way to use MMC/SD and CF (and perhaps nfs and smb remote directories) for external application storage.

[amrein]

If you ask to yourself: what is the priority between CF and MMC? It\'s depend of your configured options.
If you ask to yourself: what doesn\'t amrein like symlink? Because I have at present 8 CF and trust me I prefer plug and play.

Ouch! One symlink (/usr/local) pointing on /mnt/cf/ and modifying PATH & LD_LIBRARY_PATH should be enough for most apps. ;(
Only installation could put me into trouble (moving files and directories like /etc /var ...).

[lardman]

I heard about a FreeBSD solution that permits to merge directories content.

For exemple: files from /usr/bin + /mnt/cf/usr/bin + /mnt/sd/usr/bin are all listed and accessible from /usr/bin.
No link. No specific configuration. If you unmount the CF, its content in no more listed in /usr/bin /usr/etc , ....

Yes I also remember reading about this, but from what I remember it would require some fairly hefty changes to support it, or am I wrong? Nevertheless it would be useful.

I can\'t see a best way to use MMC/SD and CF (and perhaps nfs and smb remote directories) for external application storage.

I used to mount /usr/local from an MMC card, but I\'ve come around to just using ipkg\'s symlinking abilities to symlink everything which I\'ve installed to \'SD\' into the correct location - it takes (slightly) more memory, but at least it\'s neater (IMO).

I believe ipk is just a \"tar\" with relative paths.. ie: the paths don\'t start with /

I\'d check this out, my understanding was that an ipk is either an ar archive or a tar.gz archive containing 3 files (which have relative paths) - control.tar.gz (which contains scripts if needed - relative paths I think), debian-binary (a file containing the number \'2\') and data.tar.gz which contains the actual files (with absolute paths - e.g. you should \'cd / && tar -zxvf data.tar.gz\').


Si

[zxerx]

I\'ve been playing with ipkg-link and it appears to mostly do what it\'s supposed to (had trouble with linking a root that was deeply nested on an nfs server). I will more than likely use this method as it\'s a quick fix. (ie: some programs that refer to /etc/whatever in their postinst script can\'t find anything because the file is really in /mnt/wherever/etc/whatever).

I still think most packages should be uisng /usr/local/ - I mean, that is the whole concept behind having /usr/local originally right - so we can have stuff specific to each installation on a seperate filesystem. I guess all these sorts of things will get ironed out as the project matures....