[buildd-tools-devel] remove build dependency alternative mangling from sbuild

[Johannes Schauer]

Hi,

currently, sbuild (and buildd) by default mangle build dependencies before
passing them to apt in the following way:

  Keep the first alternative and all subsequent alternatives with the same
  dependency name as the first but drop the rest.

Apparently it was introduced in 2011 with commit 96efc522.

I would like to find out why this mangling is still useful in 2016. I see the
following disadvantages:

 - Debian-specific build dependency resolution compared to derivatives
 - limited tool support to emulate this behaviour locally
 - does not solve the problem it is meant to solve
 - is already solved properly by apt

In dose3 we implemented --deb-emulate-sbuild to make it possible to check
buildd behaviour locally. I now talked with apt people about the possibility to
add it to their "apt-get build-dep" logic. But before more tools add a switch
to differentiate between Debian build behaviour and normal behaviour, I wanted
to bring up the necessity of it here.

I do not see an upside of this behaviour of sbuild/buildd. The relevant bug is
#614807 which tries to document this behaviour in policy. Let me cite from the
proposed patch:

 | Also note that while <tt>Build-Depends</tt> and <tt>Build-Depends-Indep</tt>
 | permit the use of alternative dependencies, these are not normally used by
 | the Debian autobuilders.  A key criterion for building binary packages for
 | inclusion in the main Debian archive is that the build must be consistently
 | reproducible, for example using the same toolchain, and linking against the
 | same libraries.  Alternative dependencies introduce inconsistency because
 | the set of packages which will be used for the build can vary.  To avoid
 | this, the autobuilders will use only the first alternative, and will ignore
 | all other alternatives.  This does not include architecture restrictions,
 | which are reduced to just those needed by the build architecture prior to
 | alternative removal.  Alternatives may therefore be used to allow building
 | the same package in different distributions, for example unstable, stable,
 | backports and experimental, but the first dependency is the one which will
 | be used to build for the distribution set in <file>debian/changelog</file>.

I do not think that this argument has much merit. Just filtering the direct
dependencies will *not* give you a unique installation set. Dependency
alternatives can occur arbitrarily deep in the dependency graph and not only at
the top level. And even at the top level, metapackages or virtual packages will
add non-uniqueness without the current method being able to do anything about
it.

Furthermore, apt already will try to install the first choice when faced with
dependency alternatives (unless another choice is already satisfied). So even
without this build dependency mangling, the solution apt chooses should be the
same.

So why do we need this ugly hack which is not solving the problem it is meant
to solve by itself, adds complexity in the user interfaces and codebase of
several software pieces, is Debian specific and is already solved by apt?

Thanks!

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