Charles Steinkuehler wrote: > > > Perhaps we can stick to a format of: > > > > name-ver-rel.lrp > > > > ...or anything where the name does NOT have a '-' in it; then the > > "shortname" would be everything up to the first '-' ... > > Several names already have dashes in them :(
We're not stuck with what the software gives us. Just replace '-' with '_' and it'll work. > 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'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 ... > IMHO, I think "freshening" the packaging format is called for, to support a > variety of new features that are impossible or cumbersome with the existing > simplistic tar.gz files. This doesn't have to be a huge leap in complexity, > just a slight twist in some basic definitions (for instance, maybe there's a > dir for each package, with a dir under that for each version, with that > directory containing the package meta-data...ie instead of > /var/lib/<package>.list, you'd have /var/lib/<package>/<version>/list, with > <package> and <version> potentially 30 characters each). NOTE: Just an > example...I don't want to start talking about ANY format changes before > figuring out what functionality we need to support...the whole cart & horse > thing, you know). 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. The new "standard" seems to be /opt... you put ALL the files in /opt, and your PATH, MANPATH, and LIBPATH variables grow without bounds :) Thus, you would have: /opt/nmap /opt/nmap/sbin /opt/nmap/lib /opt/nmap/man ...and so forth. For our case, we could add: /opt/nmap/leaf ...and files underneath it: /opt/nmap/leaf/version /opt/nmap/leaf/list /opt/nmap/leaf/desc ...of course, you still have to account for the old way: cd /var/lib/lrpkg PKG=nmap for i in /opt/$PKG/leaf/* ; do ln -s $i $PKG.$(basename $i) ...then PATH grows thus: PATH=$PATH:/opt/nmap/sbin ...and MANPATH: MANPATH=$MANPATH:/opt/nmap/man ...or perhaps, for us: HELPPATH=$HELPPATH:/opt/nmap/help > I think a few simple changes like the above would go a long way towards > allowing extended functionality, and make systems with LOTS of installed > packages a little easier to deal with (I don't know about David, but I'm > beginning to get lost when wandering around the /var/lib/lrpkg directory, > and I don't generally have nearly as many packages as he releases...maybe he > doesn't load them all?). I never go in there. I usually do one of two things: load nothing (single disk) or load the works (networking disks #1 and #2, maybe devel, maybe "setup" disk)... Loading "the works" I tend to do via the network. > 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... > Future extension of features should > generally come along for free, since if we want to support loading old LRP > packages (a big YES in my book), we'll have to do some sort of 'massaging' > of the existing package data anyway, working around any missing information > (for instance, many LRP files don't even include a proper <package>.version > file...one of many minor issues to work around in the new grand (or > not-so-grand) scheme). 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. If you have Oxygen, load the boot disk and try apkg -l once; some packages have no *.version - and indeed, some that I've done, the software has NO version to speak of. So there you are. In fact, if the changes are structural (files and directories) then the standard *.lrp can be used. The only thing the wrapper is needed for is that the package needs to be unaltered and yet be matched with its signature - a chicken and the egg problem. I would propose the following (using nmap): /opt/nmap/bin (executable locations) /opt/nmap/etc (as needed) /opt/nmap/sbin (as needed) /opt/nmap/lrp (legacy files - linked to from /var/lib/lrpkg) /opt/nmap/signature (file) /opt/nmap/leaf (new files) 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: * 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... 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 ...and the other files could be in /bin /sbin as before... _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
