XPost: linux.debian.policy   
   From: rra@debian.org   
      
   Bill Allombert  writes:   
   > On Sun, Feb 08, 2026 at 10:54:33AM -0800, Russ Allbery wrote:   
      
   >> I think that's true, if I understand what you mean by "defined," but   
   >> I'm not sure why it matters. Could you say more?   
      
   > A lot of Debian packages contain libraries and headers files that can be   
   > used by Debian users to compile software. These packages are not   
   > supposed to be restricted to the purpose of building other Debian   
   > packages.   
      
   > On the other hand Debian users are not expected to use the same flags as   
   > dpkg-buildflags set, so the libaries provided by Debian should not   
   > require the use of dpkg-buildflags.   
      
   > In the original issue leading to this bug report, it was suggested to   
   > add a flag to dpkg-buildflags that would change the ABI on some   
   > architecture. Doing so would have required users to use the same flags   
   > when compiling software using the libraries.   
      
   > Ultimately, the flags were set directly at the compiler level which   
   > sidesteps this issue as long as the user use a Debian-provided compiler.   
      
   > In conclusion, any requirement to build Debian package with a certain   
   > compiler flag must address the issue of user-build software and not rely   
   > on dpkg-buildflags.   
      
   Oh, I see. Yes, this is a very good point. That means that the utility of   
   dpkg-buildflags is probably limited to cases where we want to set default   
   flags for Debian packages by (lowercase) policy, but not cases where we   
   want to change the ABI in ways that users of libraries need to know about.   
   In other words, cases where the flags are desirable but not mandatory (and   
   the original bug to which I'm responding was focused on mandatory flags).   
      
   I do think there are a lot of remaining cases that fall into the former   
   category, though. The one that comes up a lot is hardening flags, which we   
   have sometimes pushed into the compiler and sometimes managed with   
   dpkg-buildflags. Another use case is correctly handling reproducible   
   builds, which downstream users are not as concerned with.   
      
   Given that, I think this part still does apply?   
      
   > Thus I think this sentence to be overstated:   
      
   > 'the package maintainer is prepared to track future changes to the default   
   > compiler flags and update the package as necessary'   
      
   For example, if we add new flags for reproducible builds, the packages   
   that don't use dpkg-buildflags really should pick those up, because   
   reproducible builds is a general distribution goal. "Should," not "must,"   
   but it feels to me like should is appropriate here.   
      
   I suppose if we're committed to always changing the compiler, then this   
   isn't needed and dpkg-buildflags is more of an "ought," but my impression   
   was that we preferred to use dpkg-buildflags where possible.   
      
   --   
   Russ Allbery (rra@debian.org)                 
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)