<AppMenu>
<Item label="List main packages" option="--list-main"/>
<Item label="Search Installed" option="--search"/>
</AppMenu>
The option '--list.main' or '--search' gets passed to the AppRun which then takes whatver action:
Code: Select all
if [[ $1 == '--list-main' ]] ; then
PKG_LIST=/tmp/pkg-list.$$
ls -1 /var/lib/tpkg/packages |grep -v -E '(*\-devel\-*|*\-docs\-*|*\-i18n\-*)' > $PKG_LIST
xterm -title 'Pkg-Tools Main Packages' -fn $XTERM_FONT -geometry 45x40 -e "cat $PKG_LIST |less"
rm -f $PKG_LIST
elif [[ $1 == '--search' ]] ; then
SEARCHFILE=`greq -e"Search for file: "`
cd /var/lib/tpkg/packages ;
RESULT="`grep -H $SEARCHFILE$ * 2> /dev/null`"
if [[ -n $RESULT ]] ; then
exec greq -t"Search Results" -p "$RESULT"
else
exec greq -t"Search Results" -p "No match found!"
fi
fi
You have a lotta questions -I'll try to be helpful...
# Do all libs. load to ram?
Yes, every library and program gets loaded to RAM. First, understand that the kernel does not execute any programs itself. It calls /lib/ld-linux.so.2 to do that. ld-linux is the dynamic loader. When asked to start a program for the first time, ld-linux first loads the program into RAM at an appropriate address, then looks the prog to see what symbols are in there -names of libraries the program is linked to. It then loads each of the libraries into RAM -examining each one of them for symbols and acting accordingly. It then passes these locations to the executable as it starts it.
Now, each of the libs and the program are in the RAM cache. If you stop the program all the libs and prog remain in the cache. If you *restart* the program it does not get loaded again -everything is still available in the cache. This why programs usually start faster the second time you run them.
In Puppy and other Live distro which 'run from RAM' *any running program is in two locations in RAM*. The 'run-from-RAM' has nothing to do with the above. run-from-RAM means that the main '/' file system is located in a *reserved* portion of RAM which is being treated like a hard disk. This portion of RAM is *unavailable for other use*.
When ld-linux tries to read in a file it must access the device it is on -'normally' a spinning hard disk. The file contents must be transported out of the device, over its' cable to the main bus and then sent into RAM. Of course this takes time. The reason run-from-RAM is faster is that the files are right in the RAM -where that section is being used as ramdisk. The contents must only be accessed at its' RAM address and transport over the bus (to CPU) and then loaded (over the bus again) into the cache area for use. In theory you could unload the ramdisk once everything needed was cached -but there are lots of implications and would be messy anyway.
Version-ed dirs: Any app that *writes* to /usr/share as part of its' running is doing the Wrong Thing. $HOME of course -and many times /tmp, /var/run, /var/lock. Using these 'mini-chroots' to run programs lets you completely sequester the app from your normal $HOME structure -or not. But sequestering means you can run separate versions completely apart. Everything can be written normally to $HOME, /var, wherever -or you can sequester part or all of it -using mount --bind
iso vs squashfs:
Accessing any file system will require support for that FS in the kernel -whether hard-linked in or as a module. The point is that nearly *every system* (except for embedded, maybe) will support CD's, right? But every other file system may or may not be there -very few systems run with support for every possible FS you could use. FAT might be jast as ubiquitous or more. But we can't use that for OS files anyway. One disadvantage of squashfs or other compressed FS is that even more RAM will be used temporarily to decompress the file. So, while loading the file you have one copy (compressed) in the RAM disk, a partial copy in RAM (being decompressed) and a partial copy (uncompressed) in the cache!
Using compressed FS requires more total RAM than using a non-compressed FS. Plus, decompression takes time -another trip down the bus abd back...
"If we could only configure apps" -Of course we can! Roll your own, configured as needed -patching where needed. There is *no* getting around this, sooner or later.
"Any tools for working with AppPkgs would also be AppPkgs" chicken vs. egg -again. The first one still has to be built using some other method. I think you need to separate the product from the process -if only to more clear to your users. If the product is to be AppPkg, then let the softwsre used to create them called AppPkgCreator or whatever. How else will you tell your users... You must install AppPkg in order to create AppPkgs. But you can use AppPkgs without having AppPkg installed. But you need AppPkg installed in order to install AppPkg -wasn't this supposed to be all about using software but not having to install it?
The directions to the user which I like:
1. Download the archive of the AppDir you want to use.
2. Unpack it anywhere you like.
3. Click on the icon to start the program -or first choose from startup options by right-clicking the icon.
# 3 assumes the user uses ROX-Filer (or other AppRun-aware file mgr.) Other wise the user must start the app using the path to the AppRun -and any options you were providing in the ROX right-click must be offered or handled using some other interface. BTW, gtkdialog is a bad choice because it is rarely available on non-Puppy distros.
The product should be that easy to use -most of the time anyway. But that implies a huge body of work behind the scenes to create those AppDirs.