> > Should we maybe start a sub-project to work on a new packaging format? I've > > got a lot of various ideas on possible formats and features, but no time to > > play with them :< > > I have a strong faith in the current format - even if we package up > "newfangledsoftware 2.2.2" as a *.lrp with glibc 2.0, it'll still work > in that LRP 2.9.4 somebody's running.
Most of the feature issues can be cobbled around by adding more <package>.whatever files to the package format, but I'd REALLY like to have a way of cryptographically signing packages, in preperation for making trusted downloading of packages an available feature at runtime. It may *just* be possible to do this with a single tar.gz file, but it will be tricky at best...somehow, the cryptographic signature needs to be calculated on the existing package file (probably the tar file before gzipping), then tacked on the end somehow, without changing the existing file contents. It may be possible to create a tar file, sign that file, then add the signature to the end of the tar file before gzipping. I don't know enough about the tar format to know if appending a file to the end will change any of the previous bytes, but if not, some sort of cumbersome but workable solution could probably be reached... I still think it'd be easier to just define a package header/footer that would include the crypto sig (if present), and manipulate this with dd. A default generic header (no crypto sig...minimal information) could be used if you weren't signing the package, and would only take as many bytes as we decide a minimal "leaf" package header needs to be (probably some sort of ID tag, and a minimal vesion/size field...probably 4-16 bytes). I'm also considering supporting alternate compression schemes, for package data (I'm specifically thinking of the UPX algorithms). I like UPX because of it's asymetry...it compresses better than gzip -9, but it's much slower at compressing than expanding. Just the thing for an older system that's typically uncompressing packages much more often than creating them. For grins, throw a bootable Oxygen floppy into a 486 system and see how long it takes to de-compress all the packages... > If we add a new file (*.desc) to the /var/lib/lrpkg directory, the > package STILL works in that LRP 2.9.4 ... I'm not real concerned about this form of backwards compatability. Any new package system should be able to LOAD existing packages (not hard, as long as gzip and tar are still around), but I don't think it's a requirement that old systems be able to use new packages. When I make the switch to 2.4 kernels, glibc will get updated to the latest version as well, rendering most of the code useless for the bulk of existing 2.0 glibc installs. At the same time, I'd like to see some sort of versioning or dependancies built into the packaging system, so it's at least possible to identify the libraries a particular package requires to run properly. 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
