iLiad Proposed iLiad Packaging/Installation Standard

[Chaos]

Might want a /usr/local/sbin directory as well, depending on if any true 'system' tools might ever need to be installed.

Also might not want to change the file extension from ipk (it's ipk, not ipkg - by the way), and instead use a formatting like package-name_version_iliad.ipk (such as foo-bar_1.0.4-5_iliad.ipk). We really don't need more file extensions floating around, particularly not five-character ones, in my opinion... I mean, renaming ipk into iliad, which was originally based on deb, which was packed as an .ar or .tgz archive... It gets confusing. Maybe even just use 'pure' .deb files, as Debian has some excellent tools for managing those already. Of course, I'm not an iLiad user...

(Obviously these are just ideas/suggestions, ignore them if they're not helpful. )

[jls]

I agree with "Chaos" to create /usr/local/sbin as well as to go for the established file extensions. I am a longtime Debian user and would like to see dpkg and friends on the Iliad since they are excellent, but maybe ipkg does the same job and is already on the reader.

Vote :yes





p.s. impatiently waiting for my device to arrive ! Do they handcraft every single one upon order?

[Antartica]

Two things:

1. Is it possible to have the package database in the same card as the installed programs? That would "fix" the problem with swapping cards.

2. As for the dependencies, I suppose that every package will have LD_LIBRARY_PATH set-up to include its dependencies. Is that right?

EDIT: my vote was yes, BTW.

[chrisv5]

Originally Posted by jls

p.s. impatiently waiting for my device to arrive ! Do they handcraft every single one upon order?

As you live in Germany and they are shipped from Germany, one indeed has to wonder what takes so long? I have the gut feeling they are using pen-and-paper for administration :-( That would explain a lot.

Sorry, off-topic... um... I voted "yes" :-) And I agree with "sticking to standards". I know, it is always tempting to reinvent and "improve", but... please, no new extensions, if not REALLY necessary.

[nekokami]

Originally Posted by Adam B.

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.

Could we somehow incorporate make install as part of the ipkg script wrapper?

[Adam B.]

I've made an example package that follows all the standards mentioned above. Give it a try and let me know what you think.

http://projects.mobileread.com/iliad...al/xournal.zip

The program (xournal) itself has refresh issues that I don't think I'll be able to resolve, but it's simple and small enough to make a nice test package.

I can post a tutoral and the files I used for the ipkg later...

[Adam B.]

The files I used for the ipkg-build can be found here: http://projects.mobileread.com/iliad...xournal.tar.gz

[scotty1024]

Originally Posted by Adam B.

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.

Actually you just set the prefix to "./" when you build them. Then they are very location independent. This is why start.sh sets the cd when it starts (contentLister sets the cd to /).

I will also reset HOME in the start.sh for a few apps so I can keep more stuff inside the app's directory. Some apps will provide other environment variables that can be set to over ride where things go. Some times you actually need to take the time to read the app's manual when you set out to port it to the iLiad.

With the ability to pull out storage devices at will, I would highly advise against this approach of using a shared /usr/local. ipkg is going to be very perplexed if some Average Joe swaps out a storage device containing shared .so's and puts in a storage device that doesn't contain those .so's. ipkg doesn't grok removable media.

You also need to keep in mind that iRex doesn't have the storage devices setup in removable mode (they tried but alas didn't succeed). If you are installing ipk's on the iLiad itself the storage device is left in an inconsistent state after the installer is completed.

If you are a Unix head you know to do a sync before removing the storage device. Average Joe's though will run the shiny new app, confirm it works, then take the storage device back out to put files on it to use with the shiny new app. *poof* all hell breaks loose because the iLiad hasn't flushed all the changed data out onto the storage device before it was removed.

Unpacking the ZIP on their Mac/PC avoids this issue.

Yet another issue for Average Joe's is iRex's continuing problem with auto mounting storage devices. They turn on their iLiad, run to Starbucks for a coffee, come back and see it just finish booting. Then they click on the The Forever War.rtf in Recent Documents and ... nothing. No error message, no ebook, just Recent Documents looking at them, or even more likely: a now empty Recent Documents.

Your experienced iLiad Unix Head knows the @#$! CF card didn't automount so /mnt/cf/fbreader/FBReader isn't available for contentLister to launch to view the RTF file. Your Average Joe is left sucking on his coffee and wondering why he spent so much on this pile.

These are just highlights of why I packaged things as i did for Average Joe's to use. iRex barely knows what they are doing and won't listen to folks that really do know what they are doing.

To support 3rd party development iRex needs to do more than simply release a compiler and some header files. They need to produce a reliable device that works more often than not and doesn't need to be repaired all the time.

[TadW]

Originally Posted by scotty1024

To support 3rd party development iRex needs to do more than simply release a compiler and some header files. They need to produce a reliable device that works more often than not and doesn't need to be repaired all the time.

Scotty with all due respect I think Adam's proposal is more than sufficient for our purposes. And it seems iRex is trying hard to improve the firmware to come in our direction.

You raised some important points that obviously need to be addressed. For now though it's probably enough to mention to "Average Joe" that he should always keep his storage card inserted while running custom apps.

[Adam B.]

Originally Posted by scotty1024

Actually you just set the prefix to "./" when you build them. Then they are very location independent. This is why start.sh sets the cd when it starts (contentLister sets the cd to /).

Whenever I try to compile a program with prefix=./ it will complain that it need a static directory...

[scotty1024]

Originally Posted by TadW

Scotty with all due respect I think Adam's proposal is more than sufficient for our purposes. And it seems iRex is trying hard to improve the firmware to come in our direction.

You raised some important points that obviously need to be addressed. For now though it's probably enough to mention to "Average Joe" that he should always keep his storage card inserted while running custom apps.

"More than sufficient", really?

Adam's proposal totally fails at what I think is a fundamental detail of the iLiad: there will be more upgrades.

Your root filesystem will be replaced, erased back to factory defaults, ipkg databases reset, symbolic links removed... What state will the applications on the memory cards be in then? When you click on them after iDS gets done with your iLiad what will happen? How will your Average Joe reset the applications back to a functional state? Will they get to keep all their laboriously entered options/configurations or will everything get set back to default?

Adam himself states on his own blog he's not detail oriented. Packaging systems live and die by details that Adam is seemingly not interested in.

iRex has shown no evidence to me of being hard at work fixing the firmware. With 2.9.5 they've bricked several iLiads and there is still no way to re-flash a bricked iLiad in the field? Any competent Linux firmware developer could have had that ability working before the very first iLiad ever left Germany. M told me at the beginning of November that the development work to allow field reflashing of iLiads was "under control and progressing well".

Help me out here TadW, how many months ago was that? Six right? Half a year? Hard at work?

With all due respect TadW, if I worked that hard, I'd be out of a job. And deservedly so.

Unfortunately the only people that can implement a packaging system for the iLiad are iRex. They control how the upgrades are done. They (barely) control er_registry.txt and contentLister. Only they can address the numerous fundamental flaws in the kernel they've deployed on the iLiad.

The existing ZIP file deployment scheme may not be the best but it excels in one fundamental area: it keeps itself out of the root filesystem and done correctly it requires zero effort to maintain installed applications across upgrades. The same x48 has worked on all versions released with no need for reinstall.

[ali]

Scotty, calm down.

Scotty is right in most of his points. It's just not a good idea to have parts of your OS on removable media, independent of the OS. Be it /usr/local, or c:\program files, or whatever, sooner or later you run into big trouble when you put it on removable media.

The idea I proposed somewhere in this thread (with the zip, er_registry fragments and boot scripts) specifically is that way for such reasons. It doesn't address the unmounting problem tho.


Alas, there is a need for quick&dirty apps, in the sense of "download; tar -x; configure; make; make install" without touching the app's sources. This is not too useful and will not produce "real" Iliad apps (different UI logic, clumsy xlib hack instead of real updates, etc), but works. As long as everybody knows this is a dirty hack and begging for trouble, i.e., makes a location-independent installation package once the app becomes "stable", the /usr/local hack should be okay.

And Adams proposal was much, much, much better than those that just wanted to make random directories without any sense for Unix/Linux fs logic, e.g., "_libs" and "_sharedlibs" (*shudder*).

[TadW]

scotty1024, when I said "with all due respect", I meant it by the literal definition of the word respect.

[emkay]

EDIT. Removed. It's not really worth it

[Adam B.]

Originally Posted by scotty1024

Adam's proposal totally fails at what I think is a fundamental detail of the iLiad: there will be more upgrades.

Your root filesystem will be replaced, erased back to factory defaults, ipkg databases reset, symbolic links removed... What state will the applications on the memory cards be in then? When you click on them after iDS gets done with your iLiad what will happen? How will your Average Joe reset the applications back to a functional state? Will they get to keep all their laboriously entered options/configurations or will everything get set back to default?

A home directory will be created on the memory card, preferences stored there, and configured as such in the ipkg.

Most people realize that once they install a new operating system that they have to reinstall all their programs. Why would they not assume as such when they upgrade the os on the iLiad? Another ipkg install would restore the links and allow the program to work once again. Since preferences were defined in ipkg, they will not be overwritten.