> I propose the following updates to packages, and would like to start
> using them:
>
> <pkg>.sh Shell script which takes a
> parameter - one of:
> preinst postinst prerem postrem
> ...executed by apkg at times indicated
>
> <pkg>.desc Conf file describing package:
> Description: <blah>
> Packager: Leonard U. Ser <[EMAIL PROTECTED]>
> Group: Net/Diagnostics
>
> <pkg>.req Package list: these must already be installed
I think the <pkg>.req should be based on a functionality list, not a simple
package name. There should also be some way to differentiate versions
and/or functionality. For instance, it's probably important to be able to
tell the difference between glibc versions, and between POSIXness, busybox,
and full GNU versions of some commands.
Otherwise, adding the files sounds good to me. An existing lrpkg system
should just ignore all this. One other thing that might be nice would be
some sort of cryptographic signing of the package, but I don't know if we
can find crypto code small enough to include with all floppy distributions.
Also, we'd need to jump through some hoops to tack on a crypto signature to
the end of a tar.gz file to keep it compatable with the existing package
scripts (tricky, but do-able with dd & shell code).
> These enhancements will allow:
>
> * Restarts of currently running daemons
> * HTML pages with full descriptions, etc.
> * Packager can specify package group (saves grouping problems)
Please clarify the last item...I'm not sure what you mean.
Features I consider a *MUST* in any new packaging scheme:
The ability to upgrade an installed package
Support for mixed-media bootup ie load data from a package repository
(CD-ROM/network/&c) and config data from a local writable source
(floppy/flash/&c)
The ability to backup just config data
The ability to backup user data, or just package changes (ie weblet web
pages). This could possibly be done by storing anything with a changed MD5
sum.
I think apkg has (or comes very close to having) several of these features
already.
> I've already begun using the following enhancement:
>
> <pkg>.md5 MD5 sum of all files in package
>
> The beauty is, lrpkg SHOULD just ignore all these enhancements.
>
> Anybody do any work on lrpkg to make it not ralph if <pkg>.help and/or
> <pkg>.version are missing? lrpkg should not fail for ANY reason;
> otherwise it is buggy software. I should be able to throw most any
> trash at it, and not see it fall over dead. apkg was designed with this
> in mind.
When does this happen? I've seen several packages w/o a help file, and I
think I've seen some w/o a version. What breaks?
> Anybody planning to use apkg with Dachstein?
I'd like to see Dachstein be a fairly straight-forward update to the
Materhorn/Eiger series disks. I hope to get this done in the near term,
which should happen, as I've finally gotten a bit of time to work on LEAF
stuff (in addition to being busy, I've been kind of hoping Ewald would turn
up again). I'll be tackling Dachstein as soon as I finish IPSec, likely
later this week.
I'd like to see a 'ground-up' effort including the new c libraries, 2.2/2.4
kernel support, the new packaging system (likely apkg on steroids), and
other enhancements. I don't see any reason to tie these changes to existing
releases, and by starting with a clean slate, we don't have to keep any
backwards compatibility we don't actually find useful. It might be very
convinent, for example to switch to a VFAT format for floppies, and use long
filenames for packages...
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
