Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Sean Whitton]

Hello Jonathan,

On Thu, Nov 30 2017, Jonathan Nieder wrote:

> Thanks.  As a followup, I'm a little confused at what I think is a
> wording issue:
>
>> + 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.
>
> This means if I write
>
>   Build-Depends: a | b
>
> then it will always use 'a', regardless of the release, right?

Not quite; see below.

> What is the comment about providing flexibility talking about here?
> Is it saying that I can use 'a | b' to provide flexibility for people
> building outside an autobuilder environment?

I think this is included: this is another sense of flexibility it
provides.

> To help backporters, I have used this functionality before and
> backporters have uploaded the package as-is to a backports dist that
> didn't include 'a'.  The package built against 'b'.  Was this an
> autobuilder bug?

The backports autobuilders pass --build-dep-resolver=aptitude to sbuild,
which (I believe) causes them to use alternative dependencies.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Russ Allbery]

Jonathan Nieder  writes:

> This means if I write

>   Build-Depends: a | b

> then it will always use 'a', regardless of the release, right?

If 'a' is not installable, I thought it would then install 'b', but
perhaps I'm wrong about how the buildds work?

If 'b' is already installed, I also didn't think 'a' would be installed.

Could someone confirmm how this really works?

> What is the comment about providing flexibility talking about here?
> Is it saying that I can use 'a | b' to provide flexibility for people
> building outside an autobuilder environment?

I think some of the package-building tools that don't use clean chroots
will use 'b' if it's already installed and not try to install 'a'.

> To help backporters, I have used this functionality before and
> backporters have uploaded the package as-is to a backports dist that
> didn't include 'a'.  The package built against 'b'.  Was this an
> autobuilder bug?

Yeah, that's a great question.  How does this work for backports?

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

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Thu, Nov 30 2017, Simon McVittie wrote:

>> Other than that, seconded. I'm not sure whether this is necessarily
>> how the autobuilders *should* work, but there's value in documenting
>> how the autobuilders *do* work.
>
> Thank you for reviewing this bug.
>
> Since Sean's patch doesn't require anything of package maintainers, it's
> what we call "informative", and we don't need formal seconds.  So I'm
> going to go ahead and apply the patch.

Thanks.  As a followup, I'm a little confused at what I think is a
wording issue:

> +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.

This means if I write

Build-Depends: a | b

then it will always use 'a', regardless of the release, right?

What is the comment about providing flexibility talking about here?
Is it saying that I can use 'a | b' to provide flexibility for people
building outside an autobuilder environment?

To help backporters, I have used this functionality before and
backporters have uploaded the package as-is to a backports dist that
didn't include 'a'.  The package built against 'b'.  Was this an
autobuilder bug?

Thanks,
Jonathan

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Rebecca N. Palmer]

Should this also make explicit which Debian suites have this restriction?

I thought this rule also applied to backports having found [0] in a list 
archive search, and hence have been explicitly changing dependencies for 
backports [1] instead of using alternatives.


However after finding this proposal, I checked build logs [2], which 
suggest that sid (including -ports architectures) and stable do but 
backports doesn't.  (Though we should probably check that with someone 
who knows this better before writing it into Policy...)


[0] https://lists.debian.org/debian-backports/2011/08/msg00089.html
[1] 
https://anonscm.debian.org/cgit/pkg-opencl/beignet.git/commit/?h=jessie-backports=b1cf2fe7c0d392cc4f99e31458e871de1fe2a574
[2] comparing "Merged Build-Depends" and "Filtered Build-Depends"; 
https://buildd.debian.org/status/logs.php?pkg=linux is a suitable example

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Sean Whitton]

control: tag -1 +pending

Hello Simon,

On Thu, Nov 30 2017, Simon McVittie wrote:

> 6½ years later, ideally this would mention Build-Depends-Arch too.
>
> Other than that, seconded. I'm not sure whether this is necessarily
> how the autobuilders *should* work, but there's value in documenting
> how the autobuilders *do* work.

Thank you for reviewing this bug.

Since Sean's patch doesn't require anything of package maintainers, it's
what we call "informative", and we don't need formal seconds.  So I'm
going to go ahead and apply the patch.

We're trying to reduce the number of footnotes in Policy, but in this
case I can't see a place to insert the text without interrupting the
flow.  I'm going ahead and adding it as a footnote, but I would
appreciate any suggestions for where else the text could go.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Simon McVittie]

On Sat, 26 Feb 2011 at 14:21:13 +0100, Sean Finney wrote:
> The Debian autobuilders only make use of the first alternative
> in a set of alternatives, in order to guarantee consistent,
> reproducible builds.  This does not include architecture
> restrictions, because architecture reduction takes place before
> alternative removal.  Alternatives are therefore allowed, and
> hence useful for backports and other distributions, but are not
> used by default.
> ---
>  policy.sgml |   13 +
>  1 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/policy.sgml b/policy.sgml
> index 642f672..33a3a8a 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -4446,6 +4446,19 @@ Checksums-Sha256:
>by vertical bar (pipe) symbols |.  In such a case,
>if any one of the alternative packages is installed, that
>part of the dependency is considered to be satisfied.
> +  
> +While Build-Depends and Build-Depends-Indep
> +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.
> +  
>   

6½ years later, ideally this would mention Build-Depends-Arch too.

Other than that, seconded. I'm not sure whether this is necessarily how
the autobuilders *should* work, but there's value in documenting how
the autobuilders *do* work.

Regards,
smcv

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Steve Langasek]

On Sat, Feb 26, 2011 at 10:25:48PM +, Roger Leigh wrote:
 On Sat, Feb 26, 2011 at 10:39:51AM -0800, Steve Langasek wrote:
  On Wed, Feb 23, 2011 at 05:52:27PM +0100, Cyril Brulebois wrote:

   Tiny question: you say it eases backports. But then backports get
   autobuilt on debian buildds, so will likely use the same set of
   packages as say unstable, if build-depends aren't changed specifically
   for the backports. So I'm not exactly sure it actually eases anything.

  The one aspect of the current buildd behavior not addressed here is that the
  autobuilders will only *consider* the first alternative build-dep for
  *installation*; but if at the end of b-d installation the full build-dep
  relationship is satisfied because a different package was pulled in (or
  previously installed) that satisfies one of the other alternatives, the
  build dependencies of the package as a whole are considered satisfied.

  This was touched on briefly in 20110223115755.gm31...@codelibre.net on
  debian-devel.

 Yes, this is a very good point.  None of the resolvers do a good job at
 enforcing things post-installation (historically).  And
 dpkg-buildpackage will also consider all alternatives when checking
 they are satisfied as well.

 I think that one recent change does enforce this, however.  Previously,
 the internal resolver would just pick the first alternative, and then
 do the necessary package installation/removal to satisfy things, but
 would not subsequently enforce things.  The new dependency package
 support in the apt and aptitude resolvers /will/ enforce the first-only
 alternatives installation.  This is because the arch-reduced, first-only
 alternatives are in the Depends: of the dependency package.  The other
 alternatives are not present in the Depends: at all (unless you enable
 it).  Thus, the other alternatives aren't considered, and because the
 dependency package is installed for the duration of the build, we are
 enforcing installation of the first-only alternatives under all
 circumstances, even when the build-deps could be satisfied through
 other alternatives.

 Note this isn't yet in use on the buildds, but it is present in the
 unstable sbuild.

Sorry, I wasn't meaning to suggest that the existing implementation doesn't
do a good job at enforcing.  Rather, I wanted to raise the question of
whether this is the behavior we want.  There are cases that the current
behavior supports that I don't see any other way to support in an automated
fashion (specifically in a backports context); but we may decide that the
semantics are sufficiently opaque here that we'd rather drop support for
this anyway.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Sean Finney]

Hi all,


On Wed, 2011-02-23 at 18:22 +, Roger Leigh wrote:

 Feel free to phrase it better, or even remove that part, if it's
 unclear or not too helpful.

How about the attached?  It also condenses the text and makes it a
footnote just a bit further up, as it seemed a bit more appropriate
there and since it was not describing any particular rules but more
explanatory in nature.


Sean
From 5a9f66da4f9e0ca92ed8cb4ff20225896963bf04 Mon Sep 17 00:00:00 2001
From: Sean Finney sean...@debian.org
Date: Wed, 23 Feb 2011 15:14:56 +
Subject: [PATCH] Document restrictions on alternative build dependencies

The Debian autobuilders only make use of the first alternative
in a set of alternatives, in order to guarantee consistent,
reproducible builds.  This does not include architecture
restrictions, because architecture reduction takes place before
alternative removal.  Alternatives are therefore allowed, and
hence useful for backports and other distributions, but are not
used by default.
---
 policy.sgml |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 642f672..33a3a8a 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -4446,6 +4446,19 @@ Checksums-Sha256:
   by vertical bar (pipe) symbols tt|/tt.  In such a case,
   if any one of the alternative packages is installed, that
   part of the dependency is considered to be satisfied.
+  footnote
+While ttBuild-Depends/tt and ttBuild-Depends-Indep/tt
+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.
+  /footnote
 	/p
 
 	p
-- 
1.7.2.3



signature.asc
Description: This is a digitally signed message part

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Steve Langasek]

On Wed, Feb 23, 2011 at 05:52:27PM +0100, Cyril Brulebois wrote:

 Roger Leigh rle...@debian.org (23/02/2011):
  From: Roger Leigh rle...@debian.org
  Date: Wed, 23 Feb 2011 15:14:56 +
  Subject: [PATCH] Document restrictions on alternative build dependencies

  The Debian autobuilders only make use of the first alternative
  in a set of alternatives, in order to guarantee consistent,
  reproducible builds.  This does not include architecture
  restrictions, because architecture reduction takes place before
  alternative removal.  Alternatives are therefore allowed, and
  hence useful for backports and other distributions, but are not
  used by default.
  ---
   policy.sgml |   22 ++
   1 files changed, 22 insertions(+), 0 deletions(-)

 thanks, I like the idea. (Adding Steve to Cc since he'll probably want
 to chime in.)

Wasn't really any need for that, I am subscribed to -policy. :)

 Tiny question: you say it eases backports. But then backports get
 autobuilt on debian buildds, so will likely use the same set of
 packages as say unstable, if build-depends aren't changed specifically
 for the backports. So I'm not exactly sure it actually eases anything.

The one aspect of the current buildd behavior not addressed here is that the
autobuilders will only *consider* the first alternative build-dep for
*installation*; but if at the end of b-d installation the full build-dep
relationship is satisfied because a different package was pulled in (or
previously installed) that satisfies one of the other alternatives, the
build dependencies of the package as a whole are considered satisfied.

This was touched on briefly in 20110223115755.gm31...@codelibre.net on
debian-devel.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Roger Leigh]

On Sat, Feb 26, 2011 at 02:21:13PM +0100, Sean Finney wrote:
 Hi all,
 
 
 On Wed, 2011-02-23 at 18:22 +, Roger Leigh wrote:
 
  Feel free to phrase it better, or even remove that part, if it's
  unclear or not too helpful.
 
 How about the attached?  It also condenses the text and makes it a
 footnote just a bit further up, as it seemed a bit more appropriate
 there and since it was not describing any particular rules but more
 explanatory in nature.

Thanks, that's much more concise and readable, and it's in a better
place in the text.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Roger Leigh]

On Sat, Feb 26, 2011 at 10:39:51AM -0800, Steve Langasek wrote:
 On Wed, Feb 23, 2011 at 05:52:27PM +0100, Cyril Brulebois wrote:
 
  Tiny question: you say it eases backports. But then backports get
  autobuilt on debian buildds, so will likely use the same set of
  packages as say unstable, if build-depends aren't changed specifically
  for the backports. So I'm not exactly sure it actually eases anything.
 
 The one aspect of the current buildd behavior not addressed here is that the
 autobuilders will only *consider* the first alternative build-dep for
 *installation*; but if at the end of b-d installation the full build-dep
 relationship is satisfied because a different package was pulled in (or
 previously installed) that satisfies one of the other alternatives, the
 build dependencies of the package as a whole are considered satisfied.
 
 This was touched on briefly in 20110223115755.gm31...@codelibre.net on
 debian-devel.

Yes, this is a very good point.  None of the resolvers do a good job at
enforcing things post-installation (historically).  And
dpkg-buildpackage will also consider all alternatives when checking
they are satisfied as well.

I think that one recent change does enforce this, however.  Previously,
the internal resolver would just pick the first alternative, and then
do the necessary package installation/removal to satisfy things, but
would not subsequently enforce things.  The new dependency package
support in the apt and aptitude resolvers /will/ enforce the first-only
alternatives installation.  This is because the arch-reduced, first-only
alternatives are in the Depends: of the dependency package.  The other
alternatives are not present in the Depends: at all (unless you enable
it).  Thus, the other alternatives aren't considered, and because the
dependency package is installed for the duration of the build, we are
enforcing installation of the first-only alternatives under all
circumstances, even when the build-deps could be satisfied through
other alternatives.

Note this isn't yet in use on the buildds, but it is present in the
unstable sbuild.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Roger Leigh]

On Wed, Feb 23, 2011 at 09:09:09PM +0100, Sean Finney wrote:
 On Wed, 2011-02-23 at 18:22 +, Roger Leigh wrote:
  Yes, this might need rewording.  Some people claimed it was useful for
  backports, so if the backports buildds are using the aptitude resolver,
  they could make use of the alternatives without any changes to
  debian/control; maybe it could be better phrased, since it would
  certainly work for self-built backports, or building on derivatives
  etc.?
 
 yes, think of a package that can build against libfooN or libfooN+1, but
 only libfooN+1 is in unstable, and only libfooN is in stable.  having a
 Build-Depends: libfooN+1-dev | libfooN-dev would be a very natural thing
 to do in this case.  likewise in the case of a virtual libfoo-dev 
  libfooN-dev, which would add forward compatibility in the case of
 libfooN+1-dev (providing a libfoo-dev).

Hi Sean,

If you have any suggested changes to the Policy patch which would explain
this clearly, that would be much appreciated.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Roger Leigh]

Package: debian-policy
Version: 3.9.1.0
Severity: normal

Patch attached.

-- System Information:
Debian Release: 6.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32.27-kvm-i386-20110114 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii  doc-base  0.9.5  utilities to manage online documen

-- no debconf information
From d0737d445da8bc5e860400a73d6990f542e5ac47 Mon Sep 17 00:00:00 2001
From: Roger Leigh rle...@debian.org
Date: Wed, 23 Feb 2011 15:14:56 +
Subject: [PATCH] Document restrictions on alternative build dependencies

The Debian autobuilders only make use of the first alternative
in a set of alternatives, in order to guarantee consistent,
reproducible builds.  This does not include architecture
restrictions, because architecture reduction takes place before
alternative removal.  Alternatives are therefore allowed, and
hence useful for backports and other distributions, but are not
used by default.
---
 policy.sgml |   22 ++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 642f672..4b87261 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -4586,6 +4586,28 @@ Build-Depends: foo [linux-any], bar [any-i386], baz 
[!linux-any]
  source package section of the control file (which is the
  first section).
/p
+
+   p
+ Also note that while ttBuild-Depends/tt
+ and ttBuild-Depends-Indep/tt permit the use of
+ alternative dependencies, these are not normally used by the
+ Debian autobuilders.  A key criterion for building binary
+ packages for inclusion in the main Debian archive is that
+ the build must be consistently reproducible, for example
+ using the same toolchain, and linking against the same
+ libraries.  Alternative dependencies introduce inconsistency
+ because the set of packages which will be used for the build
+ can vary.  To avoid this, the autobuilders will use only the
+ first alternative, and will ignore all other alternatives.
+ This does not include architecture restrictions, which are
+ reduced to just those needed by the build architecture prior
+ to alternative removal.  Alternatives may therefore be used
+ to allow building the same package in different
+ distributions, for example unstable, stable, backports and
+ experimental, but the first dependency is the one which will
+ be used to build for the distribution set
+ in filedebian/changelog/file.
+   /p
   /sect
 
   sect id=binarydeps
-- 
1.7.2.3

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Cyril Brulebois]

Hi,

Roger Leigh rle...@debian.org (23/02/2011):
 From: Roger Leigh rle...@debian.org
 Date: Wed, 23 Feb 2011 15:14:56 +
 Subject: [PATCH] Document restrictions on alternative build dependencies
 
 The Debian autobuilders only make use of the first alternative
 in a set of alternatives, in order to guarantee consistent,
 reproducible builds.  This does not include architecture
 restrictions, because architecture reduction takes place before
 alternative removal.  Alternatives are therefore allowed, and
 hence useful for backports and other distributions, but are not
 used by default.
 ---
  policy.sgml |   22 ++
  1 files changed, 22 insertions(+), 0 deletions(-)

thanks, I like the idea. (Adding Steve to Cc since he'll probably want
to chime in.)

Tiny question: you say it eases backports. But then backports get
autobuilt on debian buildds, so will likely use the same set of
packages as say unstable, if build-depends aren't changed specifically
for the backports. So I'm not exactly sure it actually eases anything.

KiBi.


signature.asc
Description: Digital signature

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Roger Leigh]

On Wed, Feb 23, 2011 at 05:52:27PM +0100, Cyril Brulebois wrote:
 Hi,
 
 Roger Leigh rle...@debian.org (23/02/2011):
  From: Roger Leigh rle...@debian.org
  Date: Wed, 23 Feb 2011 15:14:56 +
  Subject: [PATCH] Document restrictions on alternative build dependencies
  
  The Debian autobuilders only make use of the first alternative
  in a set of alternatives, in order to guarantee consistent,
  reproducible builds.  This does not include architecture
  restrictions, because architecture reduction takes place before
  alternative removal.  Alternatives are therefore allowed, and
  hence useful for backports and other distributions, but are not
  used by default.
  ---
   policy.sgml |   22 ++
   1 files changed, 22 insertions(+), 0 deletions(-)
 
 thanks, I like the idea. (Adding Steve to Cc since he'll probably want
 to chime in.)
 
 Tiny question: you say it eases backports. But then backports get
 autobuilt on debian buildds, so will likely use the same set of
 packages as say unstable, if build-depends aren't changed specifically
 for the backports. So I'm not exactly sure it actually eases anything.

Yes, this might need rewording.  Some people claimed it was useful for
backports, so if the backports buildds are using the aptitude resolver,
they could make use of the alternatives without any changes to
debian/control; maybe it could be better phrased, since it would
certainly work for self-built backports, or building on derivatives
etc.?

Feel free to phrase it better, or even remove that part, if it's
unclear or not too helpful.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Sean Finney]

On Wed, 2011-02-23 at 18:22 +, Roger Leigh wrote:
 Yes, this might need rewording.  Some people claimed it was useful for
 backports, so if the backports buildds are using the aptitude resolver,
 they could make use of the alternatives without any changes to
 debian/control; maybe it could be better phrased, since it would
 certainly work for self-built backports, or building on derivatives
 etc.?

yes, think of a package that can build against libfooN or libfooN+1, but
only libfooN+1 is in unstable, and only libfooN is in stable.  having a
Build-Depends: libfooN+1-dev | libfooN-dev would be a very natural thing
to do in this case.  likewise in the case of a virtual libfoo-dev 
 libfooN-dev, which would add forward compatibility in the case of
libfooN+1-dev (providing a libfoo-dev).


sean


signature.asc
Description: This is a digitally signed message part