Bill Allombert <[email protected]> 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 ([email protected]) <https://www.eyrie.org/~eagle/>
