MobileRead Forums - View Single Post - iLiad Proposed iLiad Packaging/Installation Standard

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.

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.