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
signature.asc
Description: Digital signature
