What a flaming mess. I will never, ever, again let debhelper be the workaround point for a bad decision, such as the one made by the dpkg maintainers with forcing CFLAGS. Not without being paid at twice my standard consulting rate at least. You have been warned.
So, my only interest now WRT this bug is to support dpkg-buildflags in dh and dh_auto_* in a generic manner, and to support DEB_BUILD_OPTIONS=noopt as best possible. Since dpkg-buildflags could be used to set *any* variable, it does not seem to make sense to add the build-system specific settings like "./configure CFLAGS=foo", as Marcelo earlier prototyped. Avoiding that build-system specific stuff and only setting environment variables (that are not already set) means that supporting dpkg-buildflags will not require a debhelper compat level change. So, all that's needed is for dh (when running override targets, or just generally) and dh_auto_* (for when not called by dh) to run dpkg-buildflags --export, parse the shell formatted output, and shove it into %ENV. Now, as to DEB_BUILD_OPTIONS=noopt, probably the best way would for be dh_auto_configure/dh_auto_build to support this by passing CFLAGS="-O0" drectly to configure, etc. That way it would have the most chance of turning on debugging build. But, that is in conflict with my conclusions above. And perhaps the less perfect but much simpler way to get debug builds is to use dpkg-buildflags to do it. Note that I do not feel that these changes to debhelper will make it safe to turn off dpkg-buildpackage's default CFLAGS stomping. I think it's been well argued in this bug report by Bill A. that it won't, and his analysis is probably still valid; also it's not like everything uses dh. -- see shy jo
signature.asc
Description: Digital signature
