Hello, Russ Allbery [07/Feb 10:31am -08] wrote: > 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. > > ``debian/rules`` and dpkg-buildflags > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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 accordingly. > This is normally only appropriate for packages such as ``glibc`` that have > unique build considerations.
LGTM, though as suggested by subsequent discussion, maybe you could expand the last sentence's discussion to include reference to the other sorts of packages that Bill and Simon raise -- especially the crypto libs case. -- Sean Whitton
signature.asc
Description: PGP signature
