iLiad Proposed iLiad Packaging/Installation Standard

Adam B. · 04-26-2007, 01:12 PM

This is taken from the ideas here: https://www.mobileread.com/forums/showthread.php?t=10442

Please vote in the poll whether you think this is an acceptable solution or not. If you do not believe so, state your reason in the comments. If you have any additions, please post those as well.

After it is agreed on, I can setup instructions and a dummy package/scripts/etc to aid in packaging.

Ipkg should be used as a package management system to track dependencies and libraries.

We should have a preinstall script check for and create the following symbolic links.

Quote:

/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/share -> /media/*/_local/share
/usr/local/include -> /media/*/_local/include
/usr/local/home -> /media/*/_local/home
/usr/local/programs -> /media/*/Programs

After the program is installed /usr/local/programs should contain a folder with a launcher script, manifest, and icon.
For removing an application, we can create a simple script that will execute ipkg remove applicationame. We can put this script along with a manifest and icon in /usr/local/programs/Uninstall. From there, the user can simply navigate to that folder if they want to uninstall an appliation. They can select it, have a confirmation box pop up that says "Are you sure you want to remove $program?" that they will have to select, and the ipkg command will run.
We should rename ipkg files to .iliad. This will avoid confusion and allow us to eventually put an entry in er_registry.txt.
The launching script should set $HOME to /usr/local/home. This way program specific settings are stored on the memory card. The ipkg should also define these settings so they are not overwritten when reinstalling.

Does anyone have any problems or disagreements with this? I think it solves almost every issue we would run into. The only problem I see is if a user swaps around memory cards of the same type.... but in that case, they should know that they have to reinstall all the applications.

TadW · 04-26-2007, 01:59 PM

I like all of the suggestions, so I voted YES!

Question: what happens if a file already exists? Either because its a library from another custom package, or because the user is installing an upgrade... does the ipkg packaging system ensure that upgraded library files are upgraded, but let's say customized config files left alone (or replaced once confirmed by the user)?

Alexander Turcic · 04-26-2007, 02:05 PM

My vote is: Yes.

henkvdg · 04-26-2007, 03:17 PM

I have another idea:

I see two kinds of applications.
1) Viewers - viewers can display files with certain extensions of the filename
2) Other applications (some can also be seen as viewers)

The iLiad has a system for viewers in combination with the content lister.
As I see it, a file is shown in the contentlister if it has not a period as first character of the filename and there is no Manifest.xml, because then that determines what is displayed.
If the filetype is recognized as a known type generally an icon is displayed for the filetype + the filename and comment.
When selected, an associated viewer is started with the filename as parameter. If started by the Manifest.xml file, other parameters may be added, like pagenumber, orientation, zoomfactor and offsets.

Let us assume we want to test a new viewer, for, let us say, pdf-files.
It would be nice then to be able to put a pdf-viewer on a memory card, put it in the iLiad and the iLiad would automatically recognize that there is a new viewer and use that (if there is not already a pdf-viewer running).

How could that be accomplished?

When the iLiad is started, the last thing in the startup should be scanning the root directories of the internal memory, the cards and the USB stick (if present) in a certain order to look for a viewers directory.
This directory should contain files with the name of the extension and perhaps a special extension (like "pdf" or "pdf.def" of "doc" or "doc.def") and an icon-file, like "doc.png".
Each .def file should point to the viewer application on the same memory device.

The iLiad should then dynamically register this viewer as the one to use.
When the card is removed the viewer should be unregistered.

If the iLiad would have such a software mechanism it would be very easy to test new viewers without meddling with its internals yourself.

I thought something like this was originally planned by iRex. They can comment themselves.

As other applications would not have to be bound to filetypes and the contentlister, they could just be standalone programs on a memory device or like explained earlier installed permanently on the iLiad.

The we have a third kind of software: drivers, like an USB Keyboard driver, a modem driver, etc. etc.
These should also be testable in stand-alone version and maybe, later installable permanently in the iLiad.

If we use stand-alone versions the advantage is that all iLiads would have the same software/firmware, so that each additional application will run on each iLiad and generally will run after new system upgrades (ideally).

By the way, this system would also be nice to add your own icons for all kinds of files, without meddling with the iLiad internals yourself.

My 2 cents.

Adam B. · 04-26-2007, 03:26 PM

Those are good ideas henkvdg, but it's not exactly what we're discussing here. What's up for debate is the file system layout of user installed applications, and the method for delivering and installing those. Perhaps your post is one best left for a new thread...

Alexander Turcic · 04-26-2007, 03:41 PM

henkvdg, if I understand you correctly, what you suggest is a system how to sort the various custom iLiad apps into categories and how to define standards for how to program them. Like Adam said, it's somehow different than what this poll is for, i.e. voting on the general installation routine.

Would you like me to move your post to a new thread?

henkvdg · 04-26-2007, 03:59 PM

Quote:

Originally Posted by Alexander Turcic

henkvdg, if I understand you correctly, what you suggest is a system how to sort the various custom iLiad apps into categories and how to define standards for how to program them. Like Adam said, it's somehow different than what this poll is for, i.e. voting on the general installation routine.

Would you like me to move your post to a new thread?

OK,

Actually I do not talk about how to program them, except not to depend on non-standard system software. Put about everything on a card.
If you like it to stay, put it in internal memory. Make the software location independent. So then it is easy to move it between cards, USB-stick and internal memory.
But I would like to have comments from iRex too. If they support a system it would be a great help.

The problem with the above proposed system is that it works OK with the movable memories as "fixed disks" but it presents problems if they actually are removed or swapped. So you should not do this for movable memory, or just for a session (IMHO)

Adam B. · 04-26-2007, 04:19 PM

The problem with internal memory is the limited space. There is only 128mb available in /mnt/free, and something like 4mb on /. Between libraries, programs, and shared files, I have at least 128mb used.

Most programs can't be easily modiifed to be location indemendant. When you compile them, you need to specify a directory prefix. If you do not put the program where it expects to be, it will not be able to load all of the shared files and libraries that it requires. Hence the need for a standard installation directory.

ali · 04-26-2007, 04:20 PM

Your proposal is pretty evolved, and nearly minimal invasive, that's good. Alas, there are some things I don't like. The main thing is that you fix everything to be in one place. There's no reason to install the binaries in the user-visible areas.

I think "real" applications that tweak the OS, say, alternate boot scripts, contentLister replacements and alike should be plain old .ipk's, that change the root fs and are installed and uninstalled using the shell & ipk, or using a future ipk frontend. The reason is that these things should not break if the card is missing.

And then there should be easy-to-install viewers and applications that have no trace on the root fs. Like this: You can have _local on the internal memory and just any card. Then, a viewer like WootView for .woo and .oot-files would be a zip (windows-user-friendly, and there are no extended attributes on vfat-memory-cards anyways) containing:
_local/lib/libsharedstuff.so
_local/wootview/er_registry/woo
_local/wootview/er_registry/oot
_local/wootview/boot.sh
_local/wootview/bin/wootview
and so on.

Now the core idea is to use something similar to run-parts during boot. It would
* make er_registry contain all the entries it finds in all the _local/*/er_registry/* files (in an ideal world, the opensource contentLister just scans all those dirs...). a simple search-and-replace of, say, $INSTPATH with the path where it found the registry fragment would solve PATH problems. The idea for multiple files (woo and oot) is that even novice users could choose WootView as the .woo viewer over OtherWoo by deleting _local/otherview/er_registry/woo
* run all _local/*/boot.sh to do whatever these programs need to do on boot
* modify LD_LIBRARY_PATH so that all the _local/lib stuff works

Now, if something goes wrong, just reboot without the card and everything's fine.

henkvdg · 04-26-2007, 04:25 PM

Quote:

Originally Posted by Adam B.

The problem with internal memory is the limited space. There is only 128mb available in /mnt/free, and something like 4mb on /. Between libraries, programs, and shared files, I have at least 128mb used.

Most programs can't be easily modiifed to be location indemendant. When you compile them, you need to specify a directory prefix. If you do not put the program where it expects to be, it will not be able to load all of the shared files and libraries that it requires. Hence the need for a standard installation directory.

I think, you can use Environment Variables or how-do-you-call-them.
So if a program starts, it could ask something like "where-am-I" (pwd?) and the resulting string could be used as prefix for all its files it depends on. Then you achieve position independency, I guess.

ali · 04-26-2007, 04:28 PM

Quote:

Originally Posted by Adam B.

Most programs can't be easily modiifed to be location indemendant.

Aw crap, you're right. It would be nice if a simple shell wrapper could solve that, but right now I can't tell how.

Ok, I vote for your /usr/local, plus the boot stuff I described.

ali · 04-26-2007, 04:32 PM

Quote:

Originally Posted by henkvdg

So if a program starts, it could ask something like "where-am-I" (pwd?) and the resulting string could be used as prefix for all its files it depends on. Then you achieve position independency, I guess.

I think Adam's objection is the added work in porting. Most programs you download and compile don't do it. You could go through it, look for every place where it loads something, add the logic, and it works from there. Alas, that adds to the work needed in porting, where "porter's time" seems to be a ultrascarce resource.

nekokami · 04-26-2007, 04:40 PM

Quote:

Originally Posted by henkvdg

I think, you can use Environment Variables or how-do-you-call-them.
So if a program starts, it could ask something like "where-am-I" (pwd?) and the resulting string could be used as prefix for all its files it depends on. Then you achieve position independency, I guess.

I thought so too.

I've never had to specify the directory of anything I've compiled for Solaris or mac OSX (though maybe something is happening in the make files that I haven't been paying attention to). I've often had to set environment variables so libraries could be found, though.

Adam B. · 04-26-2007, 04:54 PM

You know, I've wondered how that would work if you specified ./configure --prefix=$CURRENTDIR. I always assumed it would take whatever was in the CURRENTDIR envrionment variable when you ran the configure script.

Most programs you don't have to worry about where they are compiled for because `make install` puts everything where it needs to be.

kapoira · 04-26-2007, 05:17 PM

my vote is yes but i will explain my point of view,

i think that when we can boot form a CF i will prefer all in the normal directories....
and i don't wanna see 2 two developers for the iliad 1 for the people how are booting a zimage from the CF, and running it to have the programs in /usr/local/bin

and another how gets the iliad and want the programs in the CF or the SD card
yes i know that the developers don't have to obligate the user to buy a CF....
(we can, but i think that is not very moral)

my vote goes to yes, but we will think in the future about the little "problem" of above.

View Poll Results: Do you find this as a agreeable standard for the iLiad?
Yes	27	87.10%
No	4	12.90%
Voters: 31. You may not vote on this poll

04-26-2007, 03:17 PM	#4
henkvdg Groupie Posts: 180 Karma: 66830 Join Date: Oct 2006 Device: IREX iLiad, Pocketbook Pro 903	A flexible system for 3rd party software. I have another idea: I see two kinds of applications. 1) Viewers - viewers can display files with certain extensions of the filename 2) Other applications (some can also be seen as viewers) The iLiad has a system for viewers in combination with the content lister. As I see it, a file is shown in the contentlister if it has not a period as first character of the filename and there is no Manifest.xml, because then that determines what is displayed. If the filetype is recognized as a known type generally an icon is displayed for the filetype + the filename and comment. When selected, an associated viewer is started with the filename as parameter. If started by the Manifest.xml file, other parameters may be added, like pagenumber, orientation, zoomfactor and offsets. Let us assume we want to test a new viewer, for, let us say, pdf-files. It would be nice then to be able to put a pdf-viewer on a memory card, put it in the iLiad and the iLiad would automatically recognize that there is a new viewer and use that (if there is not already a pdf-viewer running). How could that be accomplished? When the iLiad is started, the last thing in the startup should be scanning the root directories of the internal memory, the cards and the USB stick (if present) in a certain order to look for a viewers directory. This directory should contain files with the name of the extension and perhaps a special extension (like "pdf" or "pdf.def" of "doc" or "doc.def") and an icon-file, like "doc.png". Each .def file should point to the viewer application on the same memory device. The iLiad should then dynamically register this viewer as the one to use. When the card is removed the viewer should be unregistered. If the iLiad would have such a software mechanism it would be very easy to test new viewers without meddling with its internals yourself. I thought something like this was originally planned by iRex. They can comment themselves. As other applications would not have to be bound to filetypes and the contentlister, they could just be standalone programs on a memory device or like explained earlier installed permanently on the iLiad. The we have a third kind of software: drivers, like an USB Keyboard driver, a modem driver, etc. etc. These should also be testable in stand-alone version and maybe, later installable permanently in the iLiad. If we use stand-alone versions the advantage is that all iLiads would have the same software/firmware, so that each additional application will run on each iLiad and generally will run after new system upgrades (ideally). By the way, this system would also be nice to add your own icons for all kinds of files, without meddling with the iLiad internals yourself. My 2 cents. Last edited by henkvdg; 04-26-2007 at 03:24 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Proposed changes to Fair Use in copyright law	llreader	News	17	02-19-2010 05:17 AM
der standard newspaper on iliad	harald	iRex	4	01-17-2008 04:00 PM
Proposed MobileRead newsletter	Karel	iRex	17	11-27-2006 01:58 PM
e-book Packaging Question	NatCh	Legacy E-Book Devices	13	09-06-2006 12:02 PM
Proposed Solutions for Mobile Computing	Bob Russell	Lounge	5	10-24-2005 11:56 AM

04-26-2007, 01:59 PM	#2
TadW Uebermensch Posts: 2,583 Karma: 1094606 Join Date: Jul 2003 Location: Italy Device: Kindle	I like all of the suggestions, so I voted YES! Question: what happens if a file already exists? Either because its a library from another custom package, or because the user is installing an upgrade... does the ipkg packaging system ensure that upgraded library files are upgraded, but let's say customized config files left alone (or replaced once confirmed by the user)?

04-26-2007, 02:05 PM	#3
Alexander Turcic Fully Converged Posts: 18,163 Karma: 14021202 Join Date: Oct 2002 Location: Switzerland Device: Too many to count here.	My vote is: Yes.

04-26-2007, 03:26 PM	#5
Adam B. Addicted to Porting Posts: 1,697 Karma: 7194 Join Date: Oct 2006 Location: Indianapolis, IN Device: iRex iLiad, Nokia 770, Samsung i760	Those are good ideas henkvdg, but it's not exactly what we're discussing here. What's up for debate is the file system layout of user installed applications, and the method for delivering and installing those. Perhaps your post is one best left for a new thread...

04-26-2007, 03:41 PM	#6
Alexander Turcic Fully Converged Posts: 18,163 Karma: 14021202 Join Date: Oct 2002 Location: Switzerland Device: Too many to count here.	henkvdg, if I understand you correctly, what you suggest is a system how to sort the various custom iLiad apps into categories and how to define standards for how to program them. Like Adam said, it's somehow different than what this poll is for, i.e. voting on the general installation routine. Would you like me to move your post to a new thread?

04-26-2007, 04:19 PM	#8
Adam B. Addicted to Porting Posts: 1,697 Karma: 7194 Join Date: Oct 2006 Location: Indianapolis, IN Device: iRex iLiad, Nokia 770, Samsung i760	The problem with internal memory is the limited space. There is only 128mb available in /mnt/free, and something like 4mb on /. Between libraries, programs, and shared files, I have at least 128mb used. Most programs can't be easily modiifed to be location indemendant. When you compile them, you need to specify a directory prefix. If you do not put the program where it expects to be, it will not be able to load all of the shared files and libraries that it requires. Hence the need for a standard installation directory.

04-26-2007, 04:20 PM	#9
ali Addict Posts: 302 Karma: 116 Join Date: May 2006 Device: Iliad, dude!	Your proposal is pretty evolved, and nearly minimal invasive, that's good. Alas, there are some things I don't like. The main thing is that you fix everything to be in one place. There's no reason to install the binaries in the user-visible areas. I think "real" applications that tweak the OS, say, alternate boot scripts, contentLister replacements and alike should be plain old .ipk's, that change the root fs and are installed and uninstalled using the shell & ipk, or using a future ipk frontend. The reason is that these things should not break if the card is missing. And then there should be easy-to-install viewers and applications that have no trace on the root fs. Like this: You can have _local on the internal memory and just any card. Then, a viewer like WootView for .woo and .oot-files would be a zip (windows-user-friendly, and there are no extended attributes on vfat-memory-cards anyways) containing: _local/lib/libsharedstuff.so _local/wootview/er_registry/woo _local/wootview/er_registry/oot _local/wootview/boot.sh _local/wootview/bin/wootview and so on. Now the core idea is to use something similar to run-parts during boot. It would * make er_registry contain all the entries it finds in all the _local//er_registry/ files (in an ideal world, the opensource contentLister just scans all those dirs...). a simple search-and-replace of, say, $INSTPATH with the path where it found the registry fragment would solve PATH problems. The idea for multiple files (woo and oot) is that even novice users could choose WootView as the .woo viewer over OtherWoo by deleting _local/otherview/er_registry/woo * run all _local//boot.sh to do whatever these programs need to do on boot modify LD_LIBRARY_PATH so that all the _local/lib stuff works Now, if something goes wrong, just reboot without the card and everything's fine.

04-26-2007, 04:54 PM	#14
Adam B. Addicted to Porting Posts: 1,697 Karma: 7194 Join Date: Oct 2006 Location: Indianapolis, IN Device: iRex iLiad, Nokia 770, Samsung i760	You know, I've wondered how that would work if you specified ./configure --prefix=$CURRENTDIR. I always assumed it would take whatever was in the CURRENTDIR envrionment variable when you ran the configure script. Most programs you don't have to worry about where they are compiled for because `make install` puts everything where it needs to be.

04-26-2007, 05:17 PM	#15
kapoira Connoisseur Posts: 81 Karma: 292 Join Date: Nov 2006 Device: i62HD + T68	my vote is yes but i will explain my point of view, i think that when we can boot form a CF i will prefer all in the normal directories.... and i don't wanna see 2 two developers for the iliad 1 for the people how are booting a zimage from the CF, and running it to have the programs in /usr/local/bin and another how gets the iliad and want the programs in the CF or the SD card yes i know that the developers don't have to obligate the user to buy a CF.... (we can, but i think that is not very moral) my vote goes to yes, but we will think in the future about the little "problem" of above.

Advert

Advert