Modestas Vainius wrote: > But maybe it is not such a bad idea after all? If you want to *safely* build > in parallel mode, export DEB_BUILD_OPTIONS=parallel=X manually (dpkg- > buildpackage messes with MAKEFLAGS if and only if -jX option is passed to it > regardless of DEB_BUILD_OPTIONS contents). So dpkg-buildpackage does not > violate policy. `dpkg-buildpackage -jX` != DEB_BUILD_OPTIONS=parallel=X, it > is > more. > > However, if you want to *try* to build in a parallel mode even if the package > does not declare support for it (packaging might be out of date, maintainer > might not care or something), you use `dpkg-buildpackage -jX`. There is a > rather high probability the package may build.
It'd make more sense to me if dpkg-buildpackage's interface for parallel building used the safe mode and the unsafe mode was available for users who want to set MAKEFLAGS on their own. Since dpkg-buildpackage has the option, and the option is not marked as unsafe, it's encouraging people to use it. > Do not forget that dh_auto_* makefile support has always (so far) relied upon > dpkg-buildpackage to set CFLAGS/CXXFLAGS. When a package is built with plain > `debian/rules binary`, it will frequently end up being compiled without any > optimizations and/or -g option (unless upstream is clever enough to enable > properly configured release builds by default). What is more, makefile.pm > does > not handle DEB_BUILD_OPTIONS="noopt" either. So another bug? There have already been threads pointing out that this is a misfeature in dpkg-buildpackage. (That the concerns were dismissed is why my opinion of it was low to begin with.) Anyway, packages can set CFLAGS in debian/rules while still using dh, just as they might if running make by hand. So dh doesn't prevent packages from doing the right thing. I *hope* it doesn't obfuscate things to the point that maintainers forget to do the right thing. But, I pessimistically expect that things are going to rot to the point that use of dpkg-buildpackage becomes mandatory, despite policy not requiring it, and policy will probably then be changed to require it. Which may be their actual intent. I have no opinion whether that's a good result; just don't like the way we're getting there. Anyway, what did this have to do with debhelper? I guess I feel that making debhelper work around flags set by dpkg-buildpackage is not a productive use of time. I also feel that it is worthwhile for debhelper to not block legitimate, informed use of eg, MAKEFLAGS. Hope that somehow answers your question? -- see shy jo
signature.asc
Description: Digital signature
