[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

re buildd's resolver and package's build deps

[explicit BCC to Roger]

Hi everyone, Roger,

Roger Leigh has filed a few bug reports related to how the buildd's resolver 
(either internal or any of the new ones: apt{,itude}) and I'm not sure I quiet 
Let's take for example the one filed against php5 [#614413]:

> Severity: important
> php5 is using these alternative build dependencies:
> automake (>= 1.11) | automake1.11
> libcurl4-openssl-dev | libcurl-dev
> libdb-dev (>= 4.7) | libdb4.8-dev | libdb4.6-dev,
> libjpeg-dev | libjpeg62-dev
> libmysqlclient-dev | libmysqlclient15-dev
> The build dependency resolver is currently only using the first
> alternative.  Newer resolvers use the other alternatives, and
> this can potentially lead to inconsistency between builds.

Agreed that it can lead to build-deps inconsistencies.

> Please only use one package, the one you specifically want for
> the build, and drop the alternatives.  The use of alternatives
> in build dependencies is not supported.  In particular, you really
> only want one specific version of libdb (4.8?); there must be no
> uncertainty about this when the build dæmon installs the build
> dependencies.  The same thing applies to automake and the other
> packages using alternatives.

I disagree here.
Alternatives in build-* relationships *are* mentioned by policy. In fact, 
there's even an example in section 7.1.

There's also no stated guarantee *anywhere* (including release policy) that 
the package's build deps should be consistent, much less the result.

Also, alternatives have been used ever since I joined the project for making  
backporting easier. Requiring stricter build-deps also affects that use case.

After thinking about it for a while, my opinion is that if anyone wants 
consistency to be guaranteed (e.g. in php's case that a rebuild doesn't end up 
linking php to libdb4.6 instead of libdb4.8) it should be handled on 
buildd/release team's side. The build deps as provided by the source package 
are valid.

If the package fails to build because the dependencies were resolved in a non-
standard way then an RC bug should be filed and fixed.

I abhor the idea of uselessly tightening dependencies.

Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Reply to: