[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Buildd & binary-indep



On Mon Sep 27 15:18, Russ Allbery wrote:
> > Unless I missed it in a previous discussion, I can't see what's wrong
> > with simply mandating support with a new Standards-Version as Bernhard
> > suggested.  Could you elaborate on why Build-Features seems preferable
> > since this appears to be a simple and easily implementable solution to
> > the problem?
> 
> Using simple version numbers for capabilities is bad protocol design for a
> variety of reasons, one of which being that it's not extensible to cases
> where you want the feature or capability to remain optional going forward.
> Combine that with the problems with repurposing a field that's never had
> operational effects in the past and I think this is a bad idea compared to
> some way of explicitly stating that specific features are supported.

Using the Standards-Version to indicate whether or not we have build-arch and
not making it required is clearly wrong. However, that's surely not the
suggestion? Assuming that autodetection works with dh7 et al, wouldn't it be
sensible to use "Standards-Version >= X means that autodetection works", then
require in policy that you make it possible for that to happen. This means that
nothing FTBFS (since nothing has a new standards-version yet) and that for the
majority of packages (and I believe there are only a few edge cases where it's
not true) the Standards-Version can be bumped without any changes. In the few
cases where atm the autodetection code will fail, I don't see a problem with
fixing that before moving to the latest Standards-Version.

Even just requiring the presence of build-arch/indep after a certain
Standard-Version wouldn't be the end of the world.

> Requiring listing supported features explicitly also makes it much less
> likely that someone will claim something is supported accidentally,
> without realizing the implications.
> 
> There's significant past experience in this area in IETF protocols, both
> negative experience with version numbers and positive experience with
> capability labels.

There are, of course, other reasons to prefer explicit listing (it's a shame
that the target being in the file doesn't count as explicit listing, but...), 
but I thought it was worth contributing the above.

Matt

Attachment: signature.asc
Description: Digital signature


Reply to: