From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1Ev0RB-0003ES-JZ for garchives@archives.gentoo.org; Fri, 06 Jan 2006 22:51:58 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k06MpFr9004055; Fri, 6 Jan 2006 22:51:15 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k06MnRQV021985 for ; Fri, 6 Jan 2006 22:49:27 GMT Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by smtp.gentoo.org with esmtp (Exim 4.54) id 1Ev0Ok-0007Ma-Pg for gentoo-dev@lists.gentoo.org; Fri, 06 Jan 2006 22:49:27 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ev0OY-0001Ly-Hu for gentoo-dev@gentoo.org; Fri, 06 Jan 2006 23:49:14 +0100 Received: from ip68-230-97-182.ph.ph.cox.net ([68.230.97.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jan 2006 23:49:14 +0100 Received: from 1i5t5.duncan by ip68-230-97-182.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jan 2006 23:49:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas Date: Fri, 06 Jan 2006 15:48:44 -0700 Organization: Organization? Only haphazardly. Message-ID: References: <43BDF53C.8080205@leetworks.com> <20060106053556.GD28075@nightcrawler.e-centre.net> <623652d50601060100w2bd03634i@mail.gmail.com> <1136559950.18383.11.camel@cgianelloni.nuvox.net> <20060106173901.GF28075@nightcrawler.e-centre.net> <1136575828.18383.81.camel@cgianelloni.nuvox.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-182.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news X-Archives-Salt: fb98509b-c93d-4df1-bffd-88aa5e486751 X-Archives-Hash: 042eb6adf6e066d3a90e8d8454a5a256 Chris Gianelloni posted <1136575828.18383.81.camel@cgianelloni.nuvox.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@gentoo.org mailing list