Charles Steinkuehler wrote:
> 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.
Yipes! Getting carried away a bit :-)
For me, I almost hesitated to put that in - but the way I build packages
(main binary in bin.lrp, needed dynamic libraries in libX.lrp) adding
requirements is a big win.
However, these are my goals:
1. Simplicity
2. Simplicity
3. Simplicity :-)
Versions would be nice - probably doable - though, then you get things
like "versions earlier than X" or "version X or later" or "version Z
only"... And THEN you get versions like 0.91a05072001-1 ...uhoh... or
even (gasp) 01May2000 ...or worse... Maybe versions aren't such a good
idea...
Secondly, this would be for installed packages; glibc is not an
installed package (at least, not currently); neither is busybox, nor
things like GNU sed. Also, Oxygen is likely to do away with POSIXness
altogether...
However, the idea of building in "functional" requirements is well-taken
- but not so easy to implement. For example, some things may require a
mail program - but there are at least four I know of. How do you
determine if one is present? How do you do this without any alteration
to the program on the other end? For example, a recent ssmtp.lrp could
be upgraded to some enhanced format, but Koon Wong's exim.lrp or
postfix.lrp might not.
Only thing I could see is a "multipackage" dependency, a sort of "one of
the following:" requirement. This suggests multiple lines for listing
requirements - a sort of:
Requires: X Y Z
RequiresOneOf: A B C
RequriesOneOf: H J K
...and perhaps support for "file-based" requirements:
Requires: X Y Z /usr/bin/sed
> 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).
Assuming something would fit as a crypto program, I'd say stay away from
modifying the *.tar.gz format; use the <file>.tar.gz <file>.asc
dual-file format.
Also, remember that Oxygen is likely to have support for OTHER formats
besides *.tar.gz in the future (*.tar.bz2 perhaps? or *.tar.rar?).
> > These enhancements will allow:
> > * Packager can specify package group (saves grouping problems)
>
> Please clarify the last item...I'm not sure what you mean.
I just built rain.lrp recently; I could then decide (in packing it) that
the best group would be "Network/Diagnostics", and then create this
rain.desc file:
Name: rain
Version: 0.9
Description: TCP/IP Packet Generator
Packager: David Douthitt <[EMAIL PROTECTED]>
Group: Network/Diagnostics
Then any archival system would do something like this:
PKGD=var/lib/lrpkg
cd $WORK
for p in $PACKAGES/*.lrp ; do
tar xvf $p $PKGD/${p%%.lrp}.desc
done
cat $PKGD/* | html_out
...and html_out would then generate HTML output... With the Name: and
Version: entries, a continuous scan would be possible - and it would
permit fast output. html_out would then create a new file for each
"Name:" encountered: rain.html - and so on.
However, there'd have to be some rework to make this compatable with old
packages - or they could be added manually.
> Features I consider a *MUST* in any new packaging scheme:
>
> The ability to upgrade an installed package
This, I think, may be overrated; but the *.sh file would go a long way
to making this possible.
> 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 development version of Oxygen is going a long ways towards making
the load process VERY flexible, including your requests here.
> The ability to backup just config data
apkg does this; the new setup scripts will too.
> 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.
There is already a diff.lrp; incorporating it as you desire is possible
certainly. Of course, along with diff.lrp goes patch.lrp - and with the
two together, you lose space.
> I think apkg has (or comes very close to having) several of these features
> already.
So it does.
> 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?
What I understand is, it emits a shell error message. Two places (going
from memory) come to mind. If package X has no help, and package Y no
version, try things like:
# help X
There was a program to list all of the packages loaded and a description
line and a version; try that. Go into lrpkg and tell it you want to
look at help - I forget if it is for all packages in one menu, or if you
have to ask it. If nothing happens, tell it you want help from that
package that has none.
Using lrpkg, try listing all packages (and versions) and see what
happens.
Another thing: what about packages with no *.conf file?
Another thing: what if you have 40 packages loaded with *.conf files?
The screen is only 22 or 23 or 24 lines long.
Like I said: I should be able to do all sorts of mayhem, and lrpkg
handle it in stride. It can't.
> > 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.
You're speaking of an official first release, it sounds like. I'm
talking of future upgrades to the core.
> 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...
None of what you mentioned seems to proclaim incompatability. However,
"compatability" with LRP is a minimal requirement; the only things that
are involved would be the kernel parameters and the LRP packaging
scheme.
The rest of the compatability business is basic Linux; you could rework
the filesystem - move /etc/init.d to /etc/rc.d/init.d or to /sbin/init.d
for example (I've seen it in both places) - but I don't see too much
point in it.
Only thing I'd possibly like to do in Oxygen is to move
/var/boot/modules to /lib/modules/boot (the standard location, I
understand).
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
