Re: re buildd's resolver and package's build deps
Hi Roger,
On Tue, Feb 22, 2011 at 05:08:18PM +0000, Roger Leigh wrote:
> On Mon, Feb 21, 2011 at 07:42:32PM -0600, Raphael Geissert wrote:
> > I disagree here.
> > Alternatives in build-* relationships *are* mentioned by policy. In fact,
> > there's even an example in section 7.1.
>
> This is correct. I was thinking about drafting a patch for Policy
> about this. Current Policy defines the allowed syntax for
> Build-Depends. It does not however, make any mention of existing
> conventions and best practices, which I feel should be addressed.
>
> The current "internal" build dependency resolver does not make
> any use of the alternative dependencies. It always picks the first.
It was my understanding that there are some corner cases in which it
would select the second:
- where one build-dependency (indirectly) depends on a secondly-listed
alternative, it could install the second.
- sbuild will not worry about installing the first alternative if the
second has already been installed.
but I might be mistaken about one or both of the above.
Additionally, alternative build-dependencies are often virtual packages,
to allow for future changes more easily.
> As a result:
>
> · other alternatives are untested (never used)
I would suggest that they are less tested, rather than not tested at
all.
> · we always have consistent builds (because there's only a single
> solution)
> · we have recommended against using alternative build dependencies
> since they were introduced; this was partly because sbuild didn't
> support them, but mainly because we want complete consistency
I've never been aware of such a recommendation.
At any rate, if a maintainer would wish to support backports easily
(ever more relevant now that it's on debian.org systems), having
alternative build-dependencies would make perfect sense; in those cases,
sbuild would need to pick one set of dependencies for unstable, and the
second set for backports.
[...]
> > There's also no stated guarantee *anywhere* (including release policy) that
> > the package's build deps should be consistent, much less the result.
>
> I agree that the documentation is sorely lacking in this regard.
> It is, however, an unofficial and unwritten policy. The need for
> this is fairly self-explanatory: we don't want builds to vary.
> Taking one of php5's dependencies as an example:
>
> libdb-dev (>= 4.7) | libdb4.8-dev | libdb4.6-dev
>
> This dependency permits building against no less than *three* different
> Berkeley DB versions. Given that these versions are typically
> incompatible, imagine if a new upload caused a version change. It
> could break all existing databases when the user upgrades and they are
> no longer readable. If could even be a downgrade. The same applies
> to any other libraries.
True, but the right solution for this problem is not to remove support
for alternative build-dependencies; instead, policy should make it clear
that when a package is built in unstable, no differences in alternatives
should cause a change in functionality or support for file formats.
[...]
> > Also, alternatives have been used ever since I joined the project
> > for making backporting easier. Requiring stricter build-deps also
> > affects that use case.
>
> This is one of the two non-broken use cases for alternatives (the
> other being arch-specific deps) I am aware of. However, given that
> the infrastructure has never supported alternative build-deps, I'm not
> sure how this is working out in practice. In order for it to not be
> broken, only one of the alternatives should be avilable in each suite
> you are targetting.
>
> I would recommend keeping backports on a separate VCS branch rather than
> having a single unified package.
I vehemently disagree with this recommendation. It works now, properly;
what you suggest requires merging branches every time you wish to update
the package. That introduces an extra maintenance burden for, IMHO, no
good reason.
[...]
> Currently, 1294 packages use alternatives in build dependencies. These
> fall into these categories:
>
> · Standard alternative use in the form "concrete|virtual", as used for
> normal deps on virtual packages. Is this sensible?
Yes, because buildd hosts aren't the only systems used for building
packages. The best example of that:
> · concrete|virtual
> libgl1-mesa-dev | libgl-dev
> libglu1-mesa-dev | libglu-dev
The nvidia GL libraries conflict with mesagl. If you use the non-free
nvidia driver, you cannot install libgl1-mesa-dev without removing your
display driver. Removing the libgl-dev alternatives here, is a bad idea.
Build-dependencies were originally created for the buildd hosts, and
sbuild is still the main user of build-deps; so if something is
happening which would break sbuild, then sure, that means we should
change that.
But it's important to remember that build deps aren't *just* used by
sbuild. It is not unsensible to want to build a package on your local
system; whenever that happens, having just a strict set available of
packages that can be used to build the package is cumbersome.
> OK, the above are a selection of things I pulled out of the current
> Sources file.
>
> It's common to depend on concrete|virtual. For normal packages, it's
> like saying "I want y, but if it's not available, install x as a
> default implementation of y". Is this appropriate for a build
> dependency? It certainly works /technically/, but do we want that
> level of ambiguity, especially when it concerns libraries?
Yes, provided the given alternatives are indeed alternatives, as
expressed by their shlibs files.
> Another common form is tool1|tool2, where both tools do the same thing
> (e.g. yacc variants). Should the maintainer list all possible tools,
> or just make up their minds and pick one that works? Do we really need
> to build with every version of emacs, or just the current one?
No, the maintainer should pick one, and allow the other possibilities
(presumably through virtual packages).
> Multiple library dev packages are another. Look at libgd2 above; it's
> totally horrific! The same applies to libsnmp.
Agreed, but the libgd2 example is a bit crazy in that respect (it's a
disaster waiting to happen IMO, not just because of buildd).
> Some cases are obviously supporting multiple suites, such as the
> texlive and wx examples. The question here is, should we be doing
> this, or only support what's needed to build in the targetted suite,
> e.g. unstable?
I think we should be doing this, yes.
> The need for concrete|virtual is a fundamental deficiency in our
> package management that's been unaddressed for years (see old -devel
> discussions).
Pointer?
[...]
> Java and DocBook are the two worst offenders WRT build-deps.
This statement makes no sense at all.
Both are a clear case of software where there's a spec of what output a
given input should provide. As such, whatever particular implementation
you install should not matter; the output will be the same.
As such, it makes absolute perfect sense to have alternatives available.
Whether I build with OpenJDK or the Sun JDK should not produce any
difference in functionality; so when I want to build a 0.2K Java
application, it would be best if installing the buidl dependencies does
not require me to install OpenJDK, just because that package happens to
have selected that.
[...]
> One thing we could do is get sbuild to strip all non-arch-specific
> alternatives from the Build-Dependsi, so it would never use
> alternatives, ever. This is for the "apt" and "aptitude" resolvers,
> not "internal".
This could make sense.
While the above arguments all make sense wrt building locally, there is
no reason to modify the current behaviour whereby sbuild will only look
at the first dependency (unless something else has already been
installed). After all, I do agree that predictability on buildd hosts is
a good thing...
[...]
--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html
Reply to: