On Tue, Feb 10, 2026 at 01:10:50PM -0800, Russ Allbery wrote: > Sure, I agree, we in theory could do that. In practice, I suspect we > won't, though, even if we intend to do so. > > The same has been true for new requirements. If there is a tool that > already does what Policy wants to happen, we have increasingly been > documenting use of the tool rather than describing in detail precisely > what the tool does. This is a tradeoff, since it does make it harder to > write new tools, but I think it's a realistic tradeoff given that we are > not suffering from idle hands or an excess of resources.
This trend to be short-sighted, as this will lead to the ossification of Debian. Debian Policy should stay true to its purpose. All the packaging improvement that occured this last 20 years were possible because Policy left a large latitude how packaging was done and allowed improvements to happen. One reason Policy is lacking is that the TC has sidestepped Debian policy in a number of decisions without requesting that a detailed technical policy was devised by the proposers (which then leads to ambiguities, disagreement and more referall to the TC). In this instance, Debian policy should not create an incorrect expectation that dpkg-buildflags is used by all package or that it is suitable for all packages, at least in its current unversioned form. There has already be a MBF claiming just that. Cheers, -- Bill. <[email protected]> Imagine a large red swirl here.
