[buildd-tools-devel] Bug#774415: From srebuild sbuild-wrapper to debrebuild

[Johannes Schauer]

Hi,

Quoting Niko Tyni (2016-12-15 14:04:19)
> > But then on IRC, HW42 suggested to approach this problem differently.
> > Instead of integrating the functionality of figuring out the right
> > repositories to reproduce the contents of a buildinfo file into sbuild,
> > write a tool that can drive any package builder (like pbuilder).
> 
> Thanks for your work. I had a belated look and I'm willing to (help to)
> maintain this stuff in the reproducible-builds team.

thanks!

> In general, I like the concept of sbuild/pbuilder accepting .buildinfo files
> as input. This makes the user interface simple. My expectation for this mode
> of operation would be for the builder to recreate the old build as closely as
> possible.

I agree but would add that they should also have the ability to tell the user
if the checksums of the re-compiled packages do or do not match the information
in the supplied .buildinfo file.

> Like you two, I'm also wondering about the interaction of the various tools
> here.  The heavy weight lifted by this one is locating the package versions
> specified in a .buildinfo file. It seems to me that this functionality could
> also be a standalone helper tool that sbuild and pbuilder could call to
> determine the necessary apt sources.list entries.
> 
> The other somewhat generic thing that the current script does / could
> do is mangling the package build dependencies to correspond to the
> exact versions in the .buildinfo file. This is a much easier and quite
> mechanical task, but it might still be worth to make it into a filter
> that takes one .dsc and outputs a modified one with strictly versioned
> build dependencies?

Doing the latter is extremely trivial:

 - one call to Dpkg::Control->new() to parse the .buildinfo
 - one call to Dpkg::Deps::deps_parse() to parse Installed-Build-Depends
 - one loop over the result, printing it

The first step will even already be done in sbuild/pbuilder if they are the
ones accepting .builidinfo files. So this doesn't seem complicated enough to
warrant its own tool but I'm of course not stopping anybody from writing one.
:)

> With those, I'm thinking that 'sbuild foo.buildinfo' would fork out to
> buildinfo-findrepos (or whatever) and possibly buildinfo-mangledsc, and then
> read the environment variables, possible binNMU information etc. from the
> .buildinfo file by itself.
> 
> I suppose there could still be a 'debrebuild' or 'buildinfo-rebuild'
> tool that just calls a builder with a .buildinfo file and compares the
> resulting binaries.

If sbuild/pbuilder are parsing the .buildinfo themselves, then they can compare
the resulting binaries themselves as well. I think doing that would be expected
when providing a .buildinfo as input to either. Then no further wrapper would
be needed.

I don't care whether we have debrebuild as a wrapper to sbuild/pbuilder or
sbuild/pbuilder use a common tool to figure out the right lines for the
sources.list inside the chroot. I just want to have .buildinfo support for
sbuild in Stretch and if either solution is not in unstable soon, then my plan
is to just add .buildinfo support to sbuild myself so that it's still included
in the next Debian stable release.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20161215/f6979ea9/attachment.sig>