> > I think long package names should be supported by the new package > > system...you know, the one that supports crypto signitures and warns about > > missing library dependancys. > > "Mabel, he's talking about package formats again!"
I know, I know...just wack me upside the head or something ;-) > > I've been thinking about wrapping the existing LRP tarball inside a straight > > tar file, along with an (optional) crypto sig, and maybe some sort of > > package header. > > I think this would be the easiest way to go by far. Current package > management systems could use these files just be "pre-extracting" them, > and then unpacking the *.lrp file. New systems could work with the new > system. Legacy systems would be appeased by the user pre-extracting > everything and putting it on disk. Or, given a directory of *.laf (LeAF > :) files: > > # for i in *.laf ; do tar xzvf $i $(basename $i .laf).lrp ; done Well, probably not quite that simple, but easily do-able in shell-script, which is kind of the main thing I'm worried about. > I suggested the /var/lib/lrpkg/<pkg>/* structure a long time ago; I was > told (not by Charles, I think) that it was done the way it was to be > compatible with Debian or something. Hmm...this is really not a big concern of mine. How similar are lrp and deb files anyway. Anyone ever seen a translator to go from one to the other? We shouldn't stray too far afield, but moving a few files around in a pre-defined way isn't too hard to deal with. I *DO* think we need to do something like this if we go to long package names, if only to work around some of the limitations of the 30 char minix filesystem. > The new "standard" seems to be /opt... you put ALL the files in /opt, > and your PATH, MANPATH, and LIBPATH variables grow without bounds :) Time to cruise over to http://www.pathname.com/fhs and check out the latest FHS spec... > Thus, you would have: > > /opt/nmap <snip> > ...of course, you still have to account for the old way: I don't know that this is really necessary...most of the stuff we'd be adding to the filesystem would normally reside in the 4 main [/usr][/bin|/sbin] directories anyway... IIRC, /opt was for stuff you add to the machine at run-time, after install, by compiling or some-such. I would, however, like to see the packaging system be somewhat intelligent about filetypes (binaries, config files, data directories, &c), and have some user configuration settings that could control this. Maybe /bin, /sbin, and /usr are RO on your system, so stuff goes into /usr/local or /opt instead. This is the sort of thing that needs to get flushed out... > > BTW: I don't think ALL the nifty new package features need to be in place > > immediately. I'd just like them thought about and planned for, so that when > > someone DOES get around to writing support for them, they don't find > > themselves boxed in by the package definition, or wind up having to > > re-create all the existing packages. > > We just need a definition that will allow for expansion. Right now, the > expansion has been in /var/lib/lrpkg/<pkg>.* ; if we shift to a > directory like /opt/nmap/leaf/* that allows bigger choices. Also, one > way HTML was set up for expansion was this: if a browser didn't > understand the tag, it ignored it. Dachstein lrpkg and Oxygen apkg can > handle this sort of thing... Right-o... > I think we should be able to handle any standard *.lrp file. Also, with > apkg it doesn't matter if *.version is included or not - that was one of > the bugs apkg was designed to fix. Yes, importing existing LRP files is a big "must-have" feature, especially in the short-term. Support for a simple tar.gz file (ie no LRP meta-data) might also be called for (anyone played with porting trinix packages to LRP?). > Of course, this still retains all those files (now links) in the > /var/lib/lrpkg - but package management systems would still work. > However, this new layout has benefits: I like making the existing package file locations links to the new ones when changing *.LEAF (hey, weren't we going with long file-names?) to *.lrp. NOTE: The old LRP systems mv the <package>.list file to /tmp in the process of backing it up, but I think as long as the link was absolute (not relative), the old LRP backup scripts would still work... > * More compatable with modern UNIX (using /opt) > * Add-on packages are fully contained within their directory - no more > "littering" > * /opt can be a separate file system with more security - or CDROM, I > would think... Wouldn't root be the filesystem on a CD-ROM, ROMFS, or similar? How can we install packages if the FS isn't writable? I'll volunteer to do that code: #!/bin/sh echo "Sorry, please try again when you have a writeable filesystem!" >&2 :) > Of course, this format would not work for system packages like root, > modules, and other system packages... or would it? But then the meaning > of /opt is a little more vague - but: > > /opt/root/lrp > /opt/root/signature > /opt/root/leaf The 64KBit (oh wait, it's the 21'st century...) The 64MBit question is what gets stashed in the tar wrapper, and what goes in the tar.gz file inside the tar wrapper. I think it's obvious a crypto signature needs to be in the external wrapper...anything else that HAS to be there, or would be amazingly convinent? I'm also thinking about slow systems, so any add-ons should come before the big tarball file, and we may want any bits of information required to decide exactly what to do with the package available without un-gzipping the internal tarball. Anyone know if busybox tar is smart enough to stop reading the file when it finishes reading the file you requested? It seems like it should be, what with tar being the "Tape ARchiver"...you don't want to read your entire tape if you're just restoring a 2K file found at the beginning... It's looking like the -O option to tar (and supported by busybox) is going to start being very handy... 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
