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. 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. 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? 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? 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 - 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 > > Now, backports are a different story because they use a different resolver > > which will pull in alternates. > > afaik sbuild strips the alternatives while parsing the .dsc (or > d/control or whatever), before passing the information to the resolvers, > so even if you use another resolver for -bpo you still get the same > behaviour. That is correct. cheers, josch
Attachment:
signature.asc
Description: signature