* Russ Allbery <r...@debian.org> [100928 00:19]: > Roger Leigh <rle...@codelibre.net> writes: > > > 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,
I think you misunderstand the suggestion. It is not about decribing capabilities. It is about changing policy in a non-disruptive way. There really is no reason to keep build-arch and build-indep optional (the only reason would have been to allow for them becoming widespread on their own and then requiring them once that has no big effect), as every package not supporting them can support them by a single line in debian/rules: "build-arch build-indep: build". The only reason to not make them required directly is that it would make the largest part of the archive instantly RC buggy. Thus the suggestion is that there is a way to introduce new policy rules without upholding them to old packages, thus by saying a specific bug is only RC (or a bug at all) if Standards-Version says this package was made looking at the new rules. Making the field then operational is a rather different part (though still much easier than all the other heuristic approaches), but even without that I'd guess we could reach a working state in a much shorter time (people get those lintian warnings about no having current standard version, if they upgrade it they must also add that line if their build system does not support it...) Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100929092611.ga13...@pcpool00.mathematik.uni-freiburg.de