On Thu, Feb 12, 2026 at 10:51:50AM +0000, Sean Whitton wrote: > > + > > +Source packages that invoke a compiler that is supported by > > +:command:`dpkg-buildflags` should use that command to obtain the default > > +flags to pass to the compiler. See :manpage:`dpkg-buildflags(1)` for more > > +information. In many cases, this is handled automatically by the ``dh`` > > +tool provided by the debhelper package. > > + > > +Packages that require special handling of compiler flags may selectively > > +override the results of :command:`dpkg-buildflags` or avoid that command > > +entirely, but only if the package maintainer is prepared to track future > > +changes to the default compiler flags and update the package as necessary. > > +This may be necessary for packages such as ``glibc`` that have special > > +build considerations, or packages that need specific compiler flags for > > +performance or security reasons such as some crypto libraries. > > + > > .. _s-substvars: > > > > Variable substitutions: ``debian/substvars`` > > Seconded. > > I don't think Bill's valid point about being careful with our flags such > that we don't cause problems for compilation done by users means we need > to change anything in your proposed wording.
For the record: It is not possible for a change to dpkg-buildflags to affect the status of the package with respect of Debian policy, so tracking future change is simply not needed, thus including this sentence is not in the spirit of Debian policy. There is an easy change to dpkg-buildflags that would all ow all packages to use it even if they cannot apply the default flags: allow export DEB_BUILD_MAINT_OPTIONS=-all to disable all built-in flags without overriding DEB_flag_SET/APPEND/etc.). Cheers, -- Bill. <[email protected]> Imagine a large red swirl here.
