Package format in Eee Note Package Manager

I have been for some time bearing in mind making a package manager for the eee note. I have reviewed the ipk and deb format and find deb too composite for a machine of this nature, and the lack of script support in ipk to be a trouble ( if there is a 'more hardcore' zaurus programmer reading this, please comment and tell me I'm wrong here). I think that maintaining your Full Install will be more and more work as the number of packages increases so it would be nice if the Full Install could take care of the low level language and system issues and install a package manager that is self-updating, which would free you from re-packaging your FullInstall with each revision of a package.

I have a fundamental idea of the package format that others could get better on:

• the package should be a tar.gz file (low overhead and wide support)
• it should have the following aspects
• a 'files' directory which contains the list of installed files in a structure relative to the root directory of the device
• a 'scripts' directory which contains up to 4 scrips preinst, postinst, prerm, postrm which are executed as root at the appropriate time.

The other important factors are:
The 'title.txt' file (excuse the windows format) which contains a long title (maybe this is not needed noting that all file formats hold long file names now.)

1. A 'description.txt' file which contains a long account of the package.
2. a 'version' file which is an XML file containing the version in sequence for both the package and the packaging system (please advise on versioning issues)

A server serving the packages should be an http server containing all of the packages with an XML file called packagelist.xml containing a compilation of nodes which in turn contain "title", "description", and "location" containing a URL allowing one site to link to another if required.

Unluckily the slackware package format does not include the name, description, or version of the package in the format. These are crucial features. Oh well, back to making wheel by myself. Also, dependencies are an essential part of any package management system so I will need some mechanism for this. I use it in some routers and its fast and use dependencies.

I consider the package descriptor would need to have a key to identify whether or not the package is for a GUI app that is displayed in the launcher. If so, the PM should add an entry to the .Aconfig file. It should also add an entry to the Config.xml file. The two entries can be pre-made text files that continue living in the package, much like the ".desktop" files in other PM packages. It would also be nice if the PM would allow you to change the order of the Config.xml entries. The most reliable way I've found to add entries, is to use sed to place them immediately after the Sudoko entry, but that means the entries are placed on the second page in reverse order of installation.

Keep in wits that after Config.xml changed, the launcher needs to be restarted. I'm not sure if that also applies to. Aconfig and eeeserver as well, it may be a best perform to reboot after the PM exits if packages have been installed or detached. I think a tar.gz is a workable answer. If you look at the QTMail installer, I decided it was easier to extract a tar.gz than to place all the files in the requisite locations via shell script. Note that I also copy the tar.gz file to the local system, then chown it to root first. I had some issues where files extracted from a tar.gz ended up with the permissions of the original system. Also, files coming from a FAT filesystem (external SD) have different permissions as well.

It seems that I was a little incorrect about the ipkg format not having script hold up. There have been 2 generations of ipk and the latest wires scripts and dependencies. Opkg is a fork of ipkg that is vigorously maintained and uses the 2nd gen ipk format. It can also install debs if necessary. I think opkg is the go for a package management format. The client application can take care of the Config.xml and Aconfig files, and back up to the system partition somewhere, or, even better, auto-generate additions to both files so that the Config.xml and .aconfig are always in sync with the installed system.