Bug#968226: Build-Depends-If-Available

[Wouter Verhelst]

On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote:
> Wouter Verhelst  writes:
> 
> > -policy: this is a question that has come up before
> > (https://lists.debian.org/debian-devel/2016/12/msg00470.html is another
> > example that springs to mind, but I'm pretty sure there are more), so I
> > think we should document in Policy that a) buildd only looks at the
> > first dependency in alternative build-dependencies, and b) why this is
> > the case.
> 
> Policy already says:
> 
> While Build-Depends, Build-Depends-Indep and Build-Depends-Arch permit
> the use of alternative dependencies, these are not normally used by
> the Debian autobuilders. To avoid inconsistency between repeated
> builds of a package, the autobuilders will default to selecting the
> first alternative, after reducing any architecture-specific
> restrictions for the build architecture in question. While this may
> limit the usefulness of alternatives in a single release, they can
> still be used to provide flexibility in building the same package
> across multiple distributions or releases, where a particular
> dependency is met by differently named packages.
> 
> in 7.1.  However, it's hidden in a footnote.  Perhaps we should make it
> more prominant (and make it clear that it's normative), and tweak the
> wording.

Thanks, yeah, I missed that. I'll have a stab at a patch some time soon
(probably after debconf though)

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#968226: Build-Depends-If-Available

[Russ Allbery]

Wouter Verhelst  writes:

> -policy: this is a question that has come up before
> (https://lists.debian.org/debian-devel/2016/12/msg00470.html is another
> example that springs to mind, but I'm pretty sure there are more), so I
> think we should document in Policy that a) buildd only looks at the
> first dependency in alternative build-dependencies, and b) why this is
> the case.

Policy already says:

While Build-Depends, Build-Depends-Indep and Build-Depends-Arch permit
the use of alternative dependencies, these are not normally used by
the Debian autobuilders. To avoid inconsistency between repeated
builds of a package, the autobuilders will default to selecting the
first alternative, after reducing any architecture-specific
restrictions for the build architecture in question. While this may
limit the usefulness of alternatives in a single release, they can
still be used to provide flexibility in building the same package
across multiple distributions or releases, where a particular
dependency is met by differently named packages.

in 7.1.  However, it's hidden in a footnote.  Perhaps we should make it
more prominant (and make it clear that it's normative), and tweak the
wording.

-- 
Russ Allbery (r...@debian.org)  

Bug#968226: Build-Depends-If-Available

[Wouter Verhelst]

Package: debian-policy

On Sun, Aug 09, 2020 at 06:28:50PM +0100, Barak A. Pearlmutter wrote:
> I understand what you're saying, and indeed trying to encode
> "Build-Depends-If-Available: foo" as "Build-Depends: foo | something"
> is a bad idea from the get-go. After all, foo can have three states on
> an architecture: installable, unavailable, or
> available-but-uninstallable-for-some-reason. And we want different
> behaviour in the three cases: build with it, build without it, or
> delay-building-until-installable. And we can't shoehorn those three
> things into the binary logic of "foo | something".

Exactly, and therein lies the problem.

Buildd used to consider alternative build-dependencies, and it caused a
never-ending stream of package transition entanglements, because the
delay-building-until-installable thing never happened, which meant that
every rebuild of something to solve a problem would have to either be
timed very well, or would be likely to be playing a roulette game of
"will the rebuild solve all problems or create yet even more".

-policy: this is a question that has come up before
(https://lists.debian.org/debian-devel/2016/12/msg00470.html is another
example that springs to mind, but I'm pretty sure there are more), so I
think we should document in Policy that a) buildd only looks at the
first dependency in alternative build-dependencies, and b) why this is
the case.

Suggestion:

---8<---
Note that sbuild, the program which builds packages on each of Debian's
architectures, only considers the first alternative for any declared
element in the Build-Depends: header, after removing alternatives with
architecture restrictions that don't apply to the architecture on which
the package is building. All other alternatives are ignored by sbuild.

This is done so that package dependencies are predictable; previously,
sbuild would consider alternative dependencies, but it made binary
package dependencies change based on whether a particular package
happened to be installable on unstable at the time of a package rebuild.
These changes were unpredictable, and made handling transitions harder
than they needed to be.
--->8---

Not sure in which section to place this though. Thoughts?

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard