> You could use the two-file format already used for things like the Linux
> kernel, or if you really wanted, just wrap both files up like this -
> create a standard *.lrp file, then you could wrap it up into a *.srp
> file ("Secure LRP") with a digital signature.
>
> Then the unpackers would have to add just a secondary unpack for *.srp
> files:
>
> if (file is *.srp) then
>    verify signature
>    if (successful signature)
>       <handle *.LRP>
>    else
>       echo "error! invalid signature...skipping..."
>    fi
> fi

Hmm...looks like a new file format, smells like a new file format...

> Bad example.  Oxygen uses a *LOT* more packages than something such as
> LRP - I booted LRP 2.9.7 not long ago, and was surprised to see how long
> it took :)
>
> Oxygen split up root.lrp to its component parts - things like glibc,
> cron, inetd, and more are all now packages.  This leads to flexibility
> but more load time.

OK, granted.  I mainly said to use Oxygen because I figured you'd have a
stack of boot disks handy ;-)

> Oxygen supports new package archivers in development already, but it
> needs testing.  One just specifies the command line to "pack" and to
> "test" archives, then it uses those.  It predefines "gzip -9" and "gzip
> -t" or something like that...

Ok, but can you identify and use alternate compression engines on the fly
(ie automatically when booting the system) or is it a 'pick one and stick
with it' sort of setting?

Of course it's farily easy to write some code to ID various magic numbers in
compressed file formats, but it's hard to do this with shell-scipt (not that
the whole pacakge system needs to be shell-script, but it should be really
tiny).  Actually, the asymetry I like with UPX could apply here as
well...packages should be easy to de-compress/install, but can require
substantially more tools to create...especially if there's support for
storing config data seperately, perhaps in a simple tar.gz file like it's
done now.  It's the boot-loader that needs to be tiny...maybe a small
"installpkg" applet for busybox that could be compiled statically against
ulibc...

Regardless of any package format issues, I *REALLY* want to see a package
install command.  Something that lets you simply type "pkginstall
newpackage" from the command line, and it goes through the same hoops the
init scripts do when installing a packge (ie it mounts any required media,
and looks in all the same places, working just like if you'd added
"newpackage" to the LRP= line in syslinux.cfg).  apkg may already do
this...I appologize but I haven't had time to take a close look at it
recently.

> However, upx would not be useful (unless it packs nonexecutables).
> Packing executables is all good, but then there is no compression left
> to gain when the package is made.

Yes, I was thinking about UPX more as a compression engine than trying to
run with it in it's existing form.  It's the compression/decompression
algorithms I'm mainly interested in, which have been optimized for good
compression levels and cpu/memory friendly de-compression.

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to