iLiad iLiad 3rd Party programs standardization

[Henry Loenwind]

Originally Posted by Adam B.

I heard someone say that /opt is already in use on the iLiad, how about /var/opt? From there we can implement something similar to what Henry mentioned, but instead link it to /media/???/_opt. In there, we can have share, bin, lib, etc.

Using ipkg isn't a bad idea.

Yes, /opt is taken. But /usr/local is available. We should stick to some standard directory, I'd think...

Also, ipkg is already available on the iLiad, no need to put it on.

When reading the responses, I see a clear pattern:

(1) People tend to forget that the installation must be doable for everyone. This basically limits us to Drag&Drop on the PC side and Click-in-the-Content-Lister on the iLiad side.

(2) Putting one or more symlinks onto the root directory seems to be consent. However, as vfat does not support symlinks (I forgot...), we'd better go with multiple symlinks, as this allows advanced users (that can use the command line) more flexibility. What about:

/usr/local (real directory)
/usr/local/lib -> /media/*/_local/lib
/usr/local/bin -> /media/*/_local/bin
/usr/local/etc -> /media/*/_local/etc
/usr/local/var -> /media/*/_local/var
/usr/local/programs -> /media/*/programs

Could someone check if "_local" or ".local" are hidden from the content lister? If both are not, we maybe should use "/media/*/programs/internalfiles" instead to prevent cluttering the card's root directory.

(3) People seem to prefer scripts over ipgk. That apears strange to me. Most of the things, these scripts should do are already part of ipkg, in fact, it was created to do this. It should take care of duplicate libs, allow uninstallation (even if there are libs used by 2 or more programs), check disk space, etc. Google turned up this site: http://www.linkstationwiki.net/index...or_developers) Have a look.

[Henry Loenwind]

Originally Posted by narve

I've had bad experiences with this one... my iLiad is getting quite flaky when i've copied large amounts of files using USB cable. Could be my memory card, though.

That's "normal" for the iLiad.

Originally Posted by narve

Anyways, I prefer downloading files using wget or scp and unzipping on the iLiad. For some reason, zip doesn't work on the iLiad so tar.gz releases would be appreciated. If the zip-file is created by a build script, adding tar.gz support should be easy.

This reminds me of something else: A .ipkg package is just a .tar.gz that contains two more .tar.gz files, one with the data to install (you can manually extract that one if you like) and one with the control data and pre/post installation/deinstallation scripts.

[Adam B.]

Originally Posted by Henry Loenwind

People seem to prefer scripts over ipgk. That apears strange to me. Most of the things, these scripts should do are already part of ipkg, in fact, it was created to do this. It should take care of duplicate libs, allow uninstallation (even if there are libs used by 2 or more programs), check disk space, etc. Google turned up this site: http://www.linkstationwiki.net/index...or_developers) Have a look.

The problem is that you cannot simply select an ipkg file from the contentlister. A change would have to be made to the er_registry.txt in order to allow for this. The iLiad only allows running of scripts, so a script to kick off the process will be necessary.

Edit: Besides, I don't think that we should allow all ipkg files to be run anyway. I can see a user assuming all all ipkg files will work, install something that wasn't made for the iLiad, and fill up their root file system. If we force an iLiad specific script to install it, it will prevent such things from happening.

[Adam B.]

Originally Posted by Henry Loenwind

Could someone check if "_local" or ".local" are hidden from the content lister?

Both _directory and .directory are hidden. Perhaps we should use underscore to make things a bit easier for the *nix people to view/add folders and files.

[Henry Loenwind]

Originally Posted by Adam B.

The problem is that you cannot simply select an ipkg file from the contentlister. A change would have to be made to the er_registry.txt in order to allow for this. The iLiad only allows running of scripts, so a script to kick off the process will be necessary.

I know. Because of that I wrote in my first post, that we need to add a small "warpper" srcript at the moment. That script would just call ipkg. Later, when iRex provides a way to safely add extensions to the content lister, that script sould no longer neccessary.

Originally Posted by Adam B.

Edit: Besides, I don't think that we should allow all ipkg files to be run anyway. I can see a user assuming all all ipkg files will work, install something that wasn't made for the iLiad, and fill up their root file system. If we force an iLiad specific script to install it, it will prevent such things from happening.

Good point. However, I'd prefer to simply use another extension, maybe ".iliad". ipkg shouldn't be picky about that...

And BTW, someone could write a graphical ipkg frontend. With scripts that would be rather hard to do in a reliable way. I could imagine that iRex would be willing to add that frontend to the standard installation if it was well written and included a big enough warning message.

Underscore works? Good, I'd prefer that to the dot, too.

[smoogle]

I like the idea of a .illiad file that we can use- especially with the mockup. Some standard uncompress in-place then setup in one bundle would be neat.

For uninstalling- what did you people think of my proposal to simply have them delete the folder? i.e. leaving dangling links.

[Adam B.]

Well, here's a question, is it best to do a per-application install, or to install everything into a single directory eg: /usr/local/bin. Either way would technically work, and if you use ipkg, you could run an ipkg remove to delete it. But as you say, the average user isn't going to have access to the command line.

[Henry Loenwind]

Originally Posted by Adam B.

Well, here's a question, is it best to do a per-application install, or to install everything into a single directory eg: /usr/local/bin. Either way would technically work, and if you use ipkg, you could run an ipkg remove to delete it. But as you say, the average user isn't going to have access to the command line.

For applications that the user does not need to click on in the Content Lister, /usr/local/bin would be the usual way to go. Apps he has to click on to start, I proposed the /media/*/programs (symlinked from /usr/local/programs) for. However, whether to place the whole app there or just a manifest and starter script, mmmh, I'm not sure. Putting all in one directory allows the user to "uninstall" an app by deleting without leaving too many traces behind.

ipkg remove could be included in the GUI frontend. But that's a feature for version 2 or so...

---

PS: Just two examples of .ipkg contents:

(1) Standalone application (e.g. emelFM2, go, xtetris, ...)

/usr/local/programs/APP/manifest.xml
/usr/local/programs/APP/app.sh
/usr/local/programs/APP/app
/usr/local/programs/APP/app.so
depends: iliadx11

(2) Library package (e.g. patched X11 libs, GD, libxml)

/usr/local/lib/lib.so -> lib.2.so
/usr/local/lib/lib.2.so -> lib.2.0.3.so
/usr/local/lib/lib.2.0.3.so
/usr/local/etc/lib.conf

(3) "indirect" application (e.g. fbreader, open office)

/usr/local/lib/ipp.so
/usr/local/bin/ipp
/usr/local/etc/ipp.conf
/usr/local/var/fonts/helv.ttf
post-install script: add to content lister
pre-deinstall script: remove from content lister

Note: Type 3 depends on not-yet-existing feature of safely extendable content lister configuration.

(4) command line application (e.g. screenshot utility, Perl)

/usr/local/lib/cpp.so
/usr/local/bin/cpp
/usr/local/etc/cpp.conf
/usr/local/lib/perl/lib/*

Note: Type 4 applications are for power users.

[mtas]

Originally Posted by Henry Loenwind

For applications that the user does not need to click on in the Content Lister, /usr/local/bin would be the usual way to go. Apps he has to click on to start, I proposed the /media/*/programs (symlinked from /usr/local/programs) for. However, whether to place the whole app there or just a manifest and starter script, mmmh, I'm not sure. Putting all in one directory allows the user to "uninstall" an app by deleting without leaving too many traces behind.

ipkg remove could be included in the GUI frontend. But that's a feature for version 2 or so...

Enough talk . I've now created two scripts that should be interesting.

The first one does the following:

• Creates the directory additional_progs in the root of the file system from where it is run
• Creates the hidden directory _local under additional progs
• Creates the directory home under additional_progs/_local and a file named environment in that directory. This file contains environment variables that should be common for all locally installed programs.
• Finally it makes a symlink from /usr/local to additional_progs/_local

This should set-up a reasonable "skeleton" for installing local applications.

The other one is an ipkg file embedded in a shell script. In this way you can simply select this script with the content lister and the ipkg package will be installed in /usr/local and a directory will be created in additional_progs. This directory contains the usual manifest.xml, icon and a script to execute the installed program. The script also sources the file /usr/local/home/environment mentioned above so that DISPLAY and LD_LIBRARY_PATH is set correctly.

So, now that I've stolen an hour of my employers time I'll go home and test it. If it works out OK I'll post it tomorrow.

[mtas]

A short update. I've tested the scripts I mentioned yesterday and they work for me.

I've attached them for those of you that feels adventurous .

Basically there are three files attached, additional_progs.zip contains a directory that can be copied to /usr/share/contentlister/mode/(your_language). This one adds an entry to the contentlister menu that will point to the locally installed programs (/usr/local/additional_progs).

The second one: create_local.zip will create the necessary directory structure needed in the root of the file system it is run from. I.e. if you place it somewhere on a CF card it will create needed directories/files on the top level of that card. It will also create a symlink from /usr/local to the directory local that the script has created. For a CF card the structure created will look like this:

/usr/local -> /media/cf/local

/media/cf/local
/media/cf/local/additional_progs (this is where start-up scripts should go)
/media/cf/local/home (contains the file environment that contains common environment variables)

The last file, emelfm2_install.zip contains a single shell script which has an ipkg file embedded. When run the ipkg file will be extracted and installed. A post-install script is used to set up the start-up script for the application in /usr/local/additional_progs.

Have fun

[Adam B.]

The emelfm2 install script fills up the root file system. I'm not sure how it was created, but it did not make /usr/local a symbolic link. Instead, it copied the files into that directory and filled my root file system to 100% I have SSH access, so that's not a problem. I don't know if it would cause issues if the system were restarted.

[tororebelde]

Hi, mtas. I was to give a try to your scripts but the second is not avaliable
Can you re-update them or check if are all right?

TIA!

[Alexander Turcic]

Originally Posted by Adam B.

Do not use the emelfm2 install script! It fills up the root file system!

I'm not sure how it was created, but it did not make /usr/local a symbolic link. Instead, it copied the files into that directory and filled my root file system to 100% I have SSH access, so that's not a problem. I don't know if it would cause issues if the system were restarted.

Done. mtas, I hope you don't mind that I temporarily removed your attachments until this issue is resolved.

Best,
Alex

[Adam B.]

Originally Posted by mtas

The second one: create_local.zip will create the necessary directory structure needed in the root of the file system it is run from. I.e. if you place it somewhere on a CF card it will create needed directories/files on the top level of that card. It will also create a symlink from /usr/local to the directory local that the script has created. For a CF card the structure created will look like this:

/usr/local -> /media/cf/local

/media/cf/local
/media/cf/local/additional_progs (this is where start-up scripts should go)
/media/cf/local/home (contains the file environment that contains common environment variables)

The last file, emelfm2_install.zip contains a single shell script which has an ipkg file embedded. When run the ipkg file will be extracted and installed. A post-install script is used to set up the start-up script for the application in /usr/local/additional_progs.

Have fun

I like your idea for the first script. I would, however, change it to /media/cf/_local so the local directory is hidden from the content lister.

Also, did you use that script in the preinstall for the emelfm2_install.sh ipkg? If you did, it did not run, or ran incorrectly. This should be a standard practice so users do not have problems with their filesystem.

[Adam B.]

Originally Posted by Alexander Turcic

Done. mtas, I hope you don't mind that I temporarily removed your attachments until this issue is resolved.

Best,
Alex

The first 2 were okay, it was only the third that would fill the root filesystem if the other was not run first.