Charles Plessy <ple...@debian.org> writes: > all our packages include a way to pass build flags to the upstream build > system, in order to implement features such as DEB_BUILD_OPTIONS=noopt. > It would have been trivial to pass the hardening flags automatically > through the same communication channel.
I don't understand what you mean. Explicit logic is required in debian/rules to handle DEB_BUILD_OPTIONS=noopt unless you use a helper system that embeds that logic. There's nothing magic about that. dh deals with it for you, of course, but it's no different so far as I can tell from the way hardening flags were implemented, except that it's much simpler to change the optimization level than it is to harden all the parts of the build. > Unfortunately, the hardening build flags have been split in three > variables. To make sure they are passed correctly, either the upstream > makefiles have to be modified, or debian/rules has to be modified. Well... it's usual to have to modify debian/rules to adjust to new features of the Debian build system, no? It's a pretty simple one-time change, isn't it? > Why couldn't we design a solution that does not require these > modifications except for corner cases ? We did... that's dh. dh 9 just picks up hardening flags and just works without any changes required for any Autoconf-enabled package, or for any package with another build system that it understands. > It does not matter that they are trivial, the point is that if most C > programs need to have the same override in debian/rules, it feels that > there is something wrong. Most C programs use Autoconf in my experience. I know that scientific software often doesn't, but I think scientific software is the significant outlier in that respect. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqao6dno....@windlord.stanford.edu
