> > IIRC, /opt was for stuff you add to the machine at run-time, after
install,
> > by compiling or some-such.
>
> However, the LEAF environment changes all that...  As I understand it,
> /opt is for OPTional packages - so libc.so-2.2.1 doesn't count, but nmap
> does.

Also, things like net-snmp go in /opt, but bash goes in /bin.  I think most
things not explicitly listed by the fhs as belonging in one of the 'main'
bin directories, can be moved to /opt.  Maybe even with support for
something like a path.d directory (/etc/path.d, /etc/<pkg>/path.d ?) where
packages can drop path extensions...

> > I would, however, like to see the packaging system be somewhat
intelligent
> > about filetypes (binaries, config files, data directories, &c),
>
> ...that either calls for "magic numbers" or file extensions...

Or yet another config file...Actually, I see this as an extension of the
package file list.  There needs to be support for paritally backing up
files, which means some rudimentary knowledge about which files are
user-changeable, and which are not.  Maybe even standardizing on including
md5 sums so package integrety could be checked and/or only modified files
could be backed up.

I already have support for a <package>.local list, that allows files to be
added to the include or exclude lists when backing up.  It'd be a simple
matter to make this the master list file, and create keys applicable for
various backup types...it's just a single character, a space, and the
file-spec you'd find in the <package>.list file, so it'd be easy to convert
to an include/exclude list when running lrpAlien on your legacy LRP
system...

> > (anyone played with porting trinix packages to
> > LRP?).
>
> I've done it several times.  It's rather simple, especially since the
> only thing needed is the LRP /var/lib/lrpkg/<pkg>.* files...

Cool...maybe the process could even be automated...

> The only reason the signatures have to be outside is that they need to
> work with the archive itself.

OK, so nothing but a crypto sig outside the wrapped extended-format-LRP
format tarball.  Now what extensions go INSIDE the LRP+/LEAF/whatever
tarball file?

Any suggestions for the extention on the internal tarball?  I vote for .leaf

> One doesn't need to determine what to do with the internal archive: it's
> a *.lrp, you install it.  Otherwise, if you just want the *.asc file:
>
> PKG=nmap
> tar xzvf $PKG.srp $PKG.asc
>
> ...should get you the package signature.  If you want, you can even
> archive the signature first so that it occurs first in the file - and
> thus the entire file doesn't have to be read to get the signature out.
> At least, I assume that would be the case - but would it?  I can't
> tell...

I'm not sure either, but that can be changed at build-time, and won't (or
shouldn't) matter to the package installer.

> > It's looking like the -O option to tar (and supported by busybox) is
going
> > to start being very handy...
>
> Not sure how.  You just extract the file to stdout, then what?  Which
> file?  Why?

I was thinking:

tar -xfO <package>.leaf <package>.tgz | gunzip | tar -x

I'd prefer not to keep duplicates of the internal tgz file around, for
systems low on space.

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