Re: depending on libssl1.0-dev, buildd fails to find it
On Mon, Dec 19, 2016 at 01:12:32PM +0100, Johannes Schauer wrote:
> Hi,
>
> 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.
>
> 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.
Yes, you select the real provider as the first alternative.
> I consider it very much as a nuisance to have this special mangling of
> build-depends activated by default in sbuild. For example for dose3 we
> introduced the --deb-emulate-sbuild option just because it was such a common
> problem that dose3 would find a solution but sbuild was unable to because it
> throws away all but the first alternative of the build dependencies.
right.
> Given that there exist transitive alternatives and virtual packages I'm also
> questioning the effectiveness of this rule. I rather find it quite unexpected
> and as Daniel's puzzlement shows rather a source of problems.
>
> Can somebody remind me why we still want to have this behaviour as the default?
Back in the olden days (and I'm talking << 2005 here, IIRC) the
behaviour you're suggesting we move to *was* the default. It caused a
never-ending nightmare of transition entanglements, because foo would
depend on bar on one architecture, but on quux on the other, and then we
do a binNMU and suddenly the dependency tree is completely different and
the transition is broken yet again.
We do *not* want to go back to that again.
> 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?
Virtual build dependencies only work if you place a provider as a first
alternative.
> In my opinion we should either:
>
> - define a way that tells resolvers which "defaults" it should use for
> resolving transitive alternatives and virtual packages for the purpose of
> "stable" build dependency resolution
That's *exactly* what we do today by placing one provider first.
> - accept that dependency resolution given alternatives and virtual packages is
> always "unstable" and deal with the resulting bugs through changes in the
> respective package metadata
That's a horror.
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
Reply to: