View Single Post
Old 04-18-2007, 10:08 PM   #5
smoogle
That dude with the thing
smoogle once ate a cherry pie in a record 7 seconds.smoogle once ate a cherry pie in a record 7 seconds.smoogle once ate a cherry pie in a record 7 seconds.smoogle once ate a cherry pie in a record 7 seconds.smoogle once ate a cherry pie in a record 7 seconds.smoogle once ate a cherry pie in a record 7 seconds.smoogle once ate a cherry pie in a record 7 seconds.smoogle once ate a cherry pie in a record 7 seconds.smoogle once ate a cherry pie in a record 7 seconds.smoogle once ate a cherry pie in a record 7 seconds.smoogle once ate a cherry pie in a record 7 seconds.
 
Posts: 20
Karma: 1904
Join Date: Apr 2007
Device: iLiad
Hello, i'm just going to respectfully disagree with your preferrence of ipkg; here are my replies initially to your points;

1) The single distinction is the use of a single file (ipkg) versus an archive which must be extracted. I don't think this is a significant hurdle for users (reasons follow).

2) Filename case should be fine if the archive is created correctly- I do not see how your error could have occured (at all).

3) The motivation is to create a single standardised script, that all programmers use. By following a per-subfolder fixed structure the script could operate in the same fashion for all programs.

Finally, the biggest point I have, is we could simply ipkg the above folder and use your ipkg-ing script (minus the need for any setup), or alternatively, as you suggest for the .ipkg extension we could support the .tar.gz extension and allow you to directly extract from within the content lister.

I do like your suggestion of a fixed filesystem at /opt, but it isn't that different form Adam B's suggestion, simply /opt instead of /home/root/Apps, personally I prefer /opt. However, I still prefer a distributed approach with symlinks rather than placing the opt directory on the card.

The final problem is to do with the 'unbrickability' of it; for some programs the reason the root filesystem must be modified, is to support the contentlister, or to add new fonts/etc (as in AbiWord); these would both not be 'fixed' by the use of an /opt directory, not saying the alternative works - but just pointing out a limitation.


The setup script I would propose would work like this:
[0) Extract the archive in-place]
1) Create /opt/programs if it does not exist - *on* the root filesystem
2) Symlink /opt/programs/fbreader to the location of this script.
3) Create a _libs directory on whatever medium is used (be in CF/MMC/root) if it does not exist.
4) Optionally, move any required libraries to the _libs directory
5) Delete any libraries from the package that are contained within _libs (if you do step #4, this implies deleting all libraries).
6) Run the program.

The other directories /opt/etc could be created as well if desired, but they would all be as symlinks to the program's location of the files, rather than copies of the files.

Now, advantages:

1) No setup. You copy the file, run the script, and it makes sure it'll work with wherever you've placed it.
2) Root filesystem changes are just symlinks elsewhere, as with yours.
3) No requirement for a fixed directory structure overall.
4) If you want, the packaging method could be ipkg/tar/whatever, as long as the script can expand it.
5) Removal is simply deleting the program folder.
6) To move the program you simply put it somewhere new and run it.

the important point to make, is the visible disk structure by both methods is the same, the key difference is this way we have relocatable folders that can be placed on whatever storage you want - you don't need to have any per-CF card setup for it to work,

I just sorta like the flexibility; and combined with a util to test whether symlinks still point to valid locations, it could even prompt you "Sorry, I couldn't find fbreader, please insert the appropriate memory card."
smoogle is offline   Reply With Quote