[gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Duncan]

Chris Gianelloni posted <1136575828.18383.81.camel@×××××××××××××××××.net>,
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@g.o mailing list