> 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 :( > What do you all think, now that a VFAT-based system is proven and > functional? 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. 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. Using long package names is definately cool, but will require great care if you want to attempt to load the packages on a legacy system. Also, keep in mind that there's a 30 character filename limit in minix, which is another potential problem (I've got several packages on RH with names much longer than 30 chars). There are lots of possible ways to gracefully deal with long package names, and even multiple versions of the same package on the system at once (potentially useful for upgrades), but most anything I can think of will break the /var/lib/lrpkg/<package>.<file> model. I'm not real worried about that, but then that's just one opinion. 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 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'd even be willing to write an "lrpAlien" that would suck in a new format package and spit out a tar.gz file usable on a legacy system...as long as I get hooks to support the nifty new package features I want :) 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. 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). 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
