Intent to commit craziness - source package unpacking

[Russ Allbery]

Ian Jackson <ijackson at chiark.greenend.org.uk> writes:
> Guido Günther writes:

>> Looking at git.debian.org I found plenty of users. I did an archive
>> import of sid during Debconf and was only ran into 20 pristine-tar
>> failures (bugs yet to be filed).

> Interesting.

My impression is that the perils and flaws of pristine-tar are highly
exaggerated, at least if you care about it mostly working rather than
being 100% reliable data storage that will never fail.  (I believe for
most Debian packages pristine-tar is essentially a convenience; you can
always grab the tarball from other sources, but it's nice to not have to
when it works well.)

> I'm not sure of the logic behind that.  I don't think dgit helps much
> with the kind of tasks that pristine-tar helps with.

The main benefit of pristine-tar is that you can clone the development
repository on any random host and do package development, build local
packages for testing, and do a package upload without having to locate any
additional pieces.  I haven't been following dgit development closely, but
it did sound like you were addressing the same use case.

>> gbp buildpackage has integration with pbuilder/cowbuilder (via
>> git-builder) and I know people are using it since its better integrated
>> into gbp since you don't need additional and it's documented in the
>> manual. The sbuild dependency is there to have people not pull in
>> cowbuilder/pbuilder so they can use --git-builder=sbuild.

> Ah.

Speaking as maintainer of the integration script between gbp buildpackage
and pbuilder/cowbuilder, I would be happy to switch to sbuild if sbuild
were clearly better, and it may be (I haven't personally looked).  The
last time I looked at sbuild was more than five years ago, and the setup
looked horribly complicated compared to pbuilder and cowbuilder and was
way more than I had time to deal with at the time.

If sbuild is now at the point where you can just apt-get install sbuild,
run a single setup command, and be ready to build packages (which is where
cowbuilder is right now), I personally would be happy to use something
that's a bit closer to what the buildds are doing.

However, cowbuilder does just work, in my experience, and it's nice to not
have to change.

Note that the same integration also works with qemubuilder, for whatever
that's worth.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>