Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions
- To: Sean Whitton <spwhitton@spwhitton.name>, 614807@bugs.debian.org
- Cc: Simon McVittie <smcv@debian.org>
- Subject: Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions
- From: Jonathan Nieder <jrnieder@gmail.com>
- Date: Thu, 30 Nov 2017 19:50:41 -0800
- Message-id: <[🔎] 20171201035041.GI20640@aiede.mtv.corp.google.com>
- Reply-to: Jonathan Nieder <jrnieder@gmail.com>, 614807@bugs.debian.org
- In-reply-to: <87h8tbe94i.fsf@iris.silentflame.com>
- References: <20110223152023.32663.35231.reportbug@nagini.codelibre.net> <20110223165227.GL21862@debian.org> <20110223182201.GQ31726@codelibre.net> <1298726473.12025.17.camel@minnika> <20110223152023.32663.35231.reportbug@nagini.codelibre.net> <20171130083715.GA18374@perpetual.pseudorandom.co.uk> <20110223152023.32663.35231.reportbug@nagini.codelibre.net> <87h8tbe94i.fsf@iris.silentflame.com> <20110223152023.32663.35231.reportbug@nagini.codelibre.net>
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
Reply to: