On Sat, Feb 07, 2026 at 10:31:20AM -0800, Russ Allbery wrote: > Ansgar <[email protected]> writes: > > This seems correct to me. We can at least make it a should in Debian > Policy, and I can see the argument that it might be a must given the > issues with time_t on 32-bit architectures. > > I'm not sure the best place to start with this given that we currently > don't talk about dpkg-buildflags at all, as you point out. Maybe it's as > simple as adding a 4.9.3 section along the following lines? > > This is very rough wording; feedback welcome. In particular, I'm a bit > worried this is too strong when it comes to flags from dpkg-buildflags > that are fine to override, such as changing the optimization level.
I am not in favor of requiring the use of dpkg-buildflags in its current form. At least dpkg-buildflag should be versionned so that package maintainers have the ability to validate any compiler flags change before it is applied to a package. Using different compiler flags than upstream is not very different from patching the source code and should be treated with the same care. The concept of building all packages with the same flags do not really make sense anyway. Packages serve different purpose. dpkg-buildflag targets 'security flags' which are not relevant or suitable for HPC software whose users require performance instead. Cheers, Bill.
