Duncan wrote: > 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.
<snip a bunch about binpkg> I think a key thing that is missing is build info that is only kept on the installed system. If we were to ever create a build server setup, we need to be able to have multiple binpkg's of the same version depending on differences between sub-arch, use flags, cflag differences, gcc version differences, etc. The key one i'm after is use flags. I'm not sure of the technical details behind it, but we need something to make the binpkgs more useful outside of the local system. Having the ebuild packed at the end is a great idea! I think its just time to extend the format to include more and possibly add things for build servers. -- Lance Albertson <[EMAIL PROTECTED]> Gentoo Infrastructure | Operations Manager --- GPG Public Key: <http://www.ramereth.net/lance.asc> Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net
signature.asc
Description: OpenPGP digital signature
