MobileRead Forums - View Single Post - iLiad iLiad 3rd Party programs standardization

Henry Loenwind · 04-18-2007, 09:20 PM

I like the idea of using ipkg to install third party programs better than using directories for the user to put onto an SD/CF card. I see three main problems with the directories approach:

(1) The user must unzip (untar, unrar, ...) an archive and then put a directory with a bunch of files on a memory card. For the average computer user this is (according to my experience) just nearly impossible. And be realistic: On the long run, the iLiad should be usable for people who don't have a clue about computers.

(2) Filename case will be shredded by this process, as the archive will be unzipped on a Windows PC in most cases. Hey, that bit me just yesterday when I tried to install Perl.

(3) The custom startscripts need to be somewhat complex. There will be dozens of versions and every programmer will roll his own speciality. How long until a "rm" (I read "recreate symlink earlier in this thread!) will misfire after the script has been released? (And I can remember one developer's bricked iLiad...)

Using ipkg and a predefined directory and symlink structure has the advantage that the user has to run a "setup script" (a single .sh file) once, and then could put .ipkg onto the iLiad to be installed. First we have to deleiver a shell script with every ipkg (containing just the ipkg call), but as soon as iRex allows for save content lister extension, .ipkg files could be made directly clickable by the setup script.

However, we should define a directory structure first, so we create us another big mixed-up disorder...

Allow me to start:

---

(1) Prior to installing the iLiad must be prepared:

Code:

mkdir /mnt/cf/opt && ln -s /mnt/cf/opt /opt
or
mkdir /mnt/card/opt && ln -s /mnt/card/opt /opt

mkdir /opt/lib
mkdir /opt/bin
mkdir /opt/etc
mkdir /opt/var
mkdir /opt/programs

One of these, as fs allows:
ln -s /opt/programs /mnt/cf/programs
ln -s /opt/programs /mnt/card/programs

This is what should go into the setup script. With some simple shell programming it can also check if there is a CF or a SD card present and create the target directory on the correct media. With the symlink as /opt, the internal filesystems of the iLiad will not be touched except for one single symlink. So the setup script will not be able to brick it.

(2) Installation packages should follow these rules:

All files shall be installed into /opt, no other part of the filesystem may be touched.
If the program is to be started directly (content lister sh-extension), it shall be installed into /opt/programs. It shall have its MANIFEST in its top-level folder (e.g. /opt/programs/fbreader/MANIFEST.xml).
Common shared libraries (.so) go into /opt/lib.
Configuration settings for into /opt/etc. Using a subfolder is recommended if having more than one file, e.g. /opt/etc/fbreader/.
Programs that are to be started from the command line, or that are added as content handler to the content lister, go into /opt/bin.

And as everything is installed into /opt, again the internal filesystems will not be touched (except for ipkg's database). No chance of bricking, if we add a check for /opt being a symlink into the ipkg-wrapper script. (and/or the preinstall script of the ipkg)

---

Is this a reasonable start? What do you developers think about it?

(I could implement the needed scripts, but I want this issue being discussed first, and not rush into creating facts.)

04-18-2007, 09:20 PM	#3
Henry Loenwind Enthusiast Posts: 28 Karma: 73 Join Date: Jul 2006	I like the idea of using ipkg to install third party programs better than using directories for the user to put onto an SD/CF card. I see three main problems with the directories approach: (1) The user must unzip (untar, unrar, ...) an archive and then put a directory with a bunch of files on a memory card. For the average computer user this is (according to my experience) just nearly impossible. And be realistic: On the long run, the iLiad should be usable for people who don't have a clue about computers. (2) Filename case will be shredded by this process, as the archive will be unzipped on a Windows PC in most cases. Hey, that bit me just yesterday when I tried to install Perl. (3) The custom startscripts need to be somewhat complex. There will be dozens of versions and every programmer will roll his own speciality. How long until a "rm" (I read "recreate symlink earlier in this thread!) will misfire after the script has been released? (And I can remember one developer's bricked iLiad...) Using ipkg and a predefined directory and symlink structure has the advantage that the user has to run a "setup script" (a single .sh file) once, and then could put .ipkg onto the iLiad to be installed. First we have to deleiver a shell script with every ipkg (containing just the ipkg call), but as soon as iRex allows for save content lister extension, .ipkg files could be made directly clickable by the setup script. However, we should define a directory structure first, so we create us another big mixed-up disorder... Allow me to start: --- (1) Prior to installing the iLiad must be prepared: Code: mkdir /mnt/cf/opt && ln -s /mnt/cf/opt /opt or mkdir /mnt/card/opt && ln -s /mnt/card/opt /opt mkdir /opt/lib mkdir /opt/bin mkdir /opt/etc mkdir /opt/var mkdir /opt/programs One of these, as fs allows: ln -s /opt/programs /mnt/cf/programs ln -s /opt/programs /mnt/card/programs This is what should go into the setup script. With some simple shell programming it can also check if there is a CF or a SD card present and create the target directory on the correct media. With the symlink as /opt, the internal filesystems of the iLiad will not be touched except for one single symlink. So the setup script will not be able to brick it. (2) Installation packages should follow these rules: All files shall be installed into /opt, no other part of the filesystem may be touched. If the program is to be started directly (content lister sh-extension), it shall be installed into /opt/programs. It shall have its MANIFEST in its top-level folder (e.g. /opt/programs/fbreader/MANIFEST.xml). Common shared libraries (.so) go into /opt/lib. Configuration settings for into /opt/etc. Using a subfolder is recommended if having more than one file, e.g. /opt/etc/fbreader/. Programs that are to be started from the command line, or that are added as content handler to the content lister, go into /opt/bin. And as everything is installed into /opt, again the internal filesystems will not be touched (except for ipkg's database). No chance of bricking, if we add a check for /opt being a symlink into the ipkg-wrapper script. (and/or the preinstall script of the ipkg) --- Is this a reasonable start? What do you developers think about it? (I could implement the needed scripts, but I want this issue being discussed first, and not rush into creating facts.)