Chris Gianelloni posted <[EMAIL PROTECTED]>, excerpted below, on Fri, 06 Jan 2006 14:30:28 -0500:
> Perhaps a good explanation of the binpkg format would be in order to > give us a chance to determine what could/should be changed? As I regularly use the binpkg features on packages I've build with FEATURES=buildpkg, I believe I can answer this: The format is really pretty simple. It's a tar.bz2 (labeled as package-ver-r#.tbz2), with some additional data appended to the end. As such, it can be handled with the usual tarball tools, save that they usually complain about the extra data at the end, but proceed anyway. I regularly open them in mc's utar virtualfs for instance, to compare what's actually tarballed in one version to what's in another or to what's on my system. The tarball itself consists of all the files in the fake-install image, that would ordinarily be transferred to the live filesystem during the qmerge step. (Note that with FEATURES=buildpkg, rather than qmerging from the fake-install image, portage creates the binpkg, then decompresses it and does the merge from it, thereby testing the binpkg in the process. If something's wrong with the binpkg, the merge will fail right away, thereby avoiding creating bad ones that cannot be relied upon.) The extra data on the end includes a plain-text (not compressed) version of the ebuild, very handy if that ebuild disappears from the tree for some reason or to compare the ebuild from when the package was built with the same one now in the tree. The rest of the data tacked on is essentially what's stored in /var/db/portage when the ebuild is actually merged. Keep in mind that the binpkg must contain all that info as it must be self-contained -- no portage tree need be available to merge from binpkg. All this extra data is packed using a call from portage to a data-packer, then simply appended (not compressed into, literally appended) to the end of the existing package-files tarball. Again, the format is such that in an emergency, the tarball itself can be extracted directly over the live filesystem, replacing whatever damaged package files created the emergency in the first place in the process. This is in fact exactly the procedure recommended in the README for emergency portage recovery (using a portage binpkg retrieved from the internet, since most don't have FEATURES=buildpkg toggled on and therefore don't have a local copy). Naturally, one is urged to backup make.conf or other such config files as may be in the package, before doing such direct extraction. The extractor will normally complain about the extra data, but will ignore it and perform the extraction anyway. It's really quite a clever system. Whoever came up with it came up with a very good thing, in my book! =8^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
