Hi Osamu, Thanks for the quick resolution to this bug. I'm happy with the change you've uploaded, so just a few reactions here to your comments - feel free to ignore:
On Fri, Oct 10, 2014 at 10:55:59PM +0900, Osamu Aoki wrote: > I agree that it is bad to have cruft in the packages uploaded to the archive. > But debmake is not meant to be used "production mode" as you imply. It > generates only "template" files. Many commented out texts are meant to be > edited out by the maintainer before upload. > > This was a longstanding bug of dh-make. If you want to output > > examples, please do it in some sort of "tutorial" mode instead of in the > > default mode of operation. > As we all agree, Debian packaging for archive upload should never be > automatic one. So the purpose of debmake is to provide template files > in "tutorial mode" as default. To me it is the inherent nature of this > type of helper scripts. I understand that this is your intention. My view, however, is that everything that can be automated in packaging should be automated, and the only time one should have to edit the packaging is when dealing with the exceptional cases. This means, to me, that the tool used for generating template packaging should not require "cleaning up" of examples. This is additional work for me to do as maintainer that could be entirely automated. > With my modification to use "###", it should be easy to detect such > unmodified files with lintian. Bug report to lintian will be my TODO > item. > I also added -Q --quiet option to remove all these ### lines. Ok, that makes sense to me. > At least, the dpkg-buildflags manpage does not deprecate the use of > buildflags.mk and gives equal position. That is why I did not put down > default.mk inclusion completely. (Even CDBS is still used widely around > GNOME.) Correct. The dpkg-buildflags author doesn't agree with me regarding buildflags.mk. On Sat, Oct 11, 2014 at 10:43:22PM +0900, Osamu Aoki wrote: > But > > include /usr/share/dpkg/architecture.mk > is tempting. > This is because the buildflag variables are exported by the dh command > but the architecture variables are exported by the dpkg-buildpackage > command. dpkg-buildpackage manpage states: The architecture variables are not exported by the dh command, but they are used internally by dh when commands such as dh_auto_configure are invoked. So in the common usage there's no need for them to be exported. On Mon, Oct 13, 2014 at 12:57:27AM +0900, Osamu Aoki wrote: > I decided not to enable "include /usr/share/dpkg/architecture.mk" in > debian/rules, despite of the fact "Reliance on exported environment > flags" in the dpkg-buildpackage manpage recommendation not to rely on > its exported variables. > Now debmake's manual document has; > | Adding "include /usr/share/dpkg/architecture.mk" to debian/rules allows > | us to use debian/rules for the quick test building. But it is good idea > | to remove it for the released package since the official build always > | use dpkg-buildpackages. I don't think this rationale is correct. Packages that are not taking steps in debian/rules to set the architecture variables should still not rely on them being set. However, this is an uncommon case if you're using dh; you rarely need to set them in debian/rules because debhelper will set them when it needs to. And if you do need to use them in debian/rules directly, I think it's still better to set them individually rather than using a make include interface. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]
signature.asc
Description: Digital signature
