Re: depending on libssl1.0-dev, buildd fails to find it
Hi!
On Mon, 2016-12-19 at 13:12:32 +0100, Johannes Schauer wrote:
> Quoting Mattia Rizzolo (2016-12-18 11:38:24)
> > On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote:
> > > As Arno hinted at, it's to have reliable builds. A transient inability
> > > to install the first arm of an alternation should caused a dep-wait
> > > state, not building with the alternate Build-Depends.
> >
> > which is kinda bullshit, as a different set of transitive
> > build-dependencies can happen due to alternatives in the dependencies of
> > any transitive build-dep, so the "have stable builds by removing
> > alternatives in the build-dep list" is really pointless.
> > For example ubuntu considers them to, there is just a switch in sbuild
> > to have it consider them.
The point has never been to try to get bit by bit reproducible builds,
but to have a reproducible intent (on the same arch and across different
arches), and no, it's not really pointless. So even though transitive
build-dependencies or dependencies can certainly affect the end result,
usually the direct build-dependencies are what supposedly has clear
and direct impact when building the package.
Say something like «libmariadb-dev | libmysql-dev», or «libssl-dev |
libgnutls-dev». The code might support both, or might enable one plugin
or another based on the present Build-Depends.
And while transitive dependencies can indeed vary, they (in many,
cases for languages that have a notion of dynamic loading/linking)
should simply be implementation details, and things that could
change back w/o affecting the package being built right now.
> exactly my opinion as well. But it's even worse:
>
> Imagine you even directly build-depend on a virtual package. There is currently
> no way to somehow "reliably" always pick the same real provider of that virtual
> package.
That's why we are not supposed to do that. :) As mentioned by Adam.
> Can somebody remind me why we still want to have this behaviour as the default?
> And why whatever arguments speak *for* this behaviour being the default are
> weighing more than the "unreliability" that is already introduced by transitive
> build dependencies and multiple providers of virtual build dependencies?
As mentioned by James upthread, and from the previous explanation, it
is to avoid having packages use the alternative dependencies, perhaps
random ones if via virtuals, when the default and preferred one is
f.ex. uninstallable due to a transition, or unavailable because it has
not yet been built on this particular arch, etc.
Thanks,
Guillemm
Reply to: