XPost: linux.debian.policy   
   From: ballombe@debian.org   
      
   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.    
      
   Imagine a large red swirl here.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)