> > 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 :-)
I like Simplicity, but that's pretty much what we've got already. I'm
thinking more along the lines of "small but flexible". I'd like to see how
much of a decent packaging system could be made with just shell scripts and
possibly a few small programs (like md5sum and possibly a crypto
signer/verifier).
> 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...
Yeah, versions can get real ugly real fast. I think there should be *some*
form of versions, though, at least for stuff like shared libraries.
> 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...
I guess I'm thinking of broader variations in the base functionality. For
instance, a minimal system might have a small busybox and some POSIXness
scripts. There might be other [root|base|whatever] packages that include a
larger busybox, or full GNU versions of the base commands. I think this
stems from the fact that I'd like to make both floppy-disk based firewalls
and single-purpose, very thin servers...
> However, the idea of building in "functional" requirements is well-taken
> - but not so easy to implement. For example, some things may require a
<snip>
Too much to think about right now, with my head wrapped up in kernel
compiling. Lots of good thoughts, though. More comments later...
> 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.
Yeah...there are several things of this sort that could be considered
'broken'. I'm not great fan of lrpkg, but would rather work on it's
replacement than spiffy it up, and I'm unaware of any show-stoppers that
prevent it from being usable (although it would be nice if it could verify
it didn't run out of RAM when backing up).
> 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).
I settled on putting my boot-time modules in /boot/lib/modules, following
the layout of my HDD machines, which create a /boot partition for stuff
required to bootstrap the system. Where did /lib/modules/boot come from?
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
