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
agree.
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.
Regards,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Reply to: