Bug#763535: debmake should not encourage use of /usr/share/dpkg/default.mk
Hi, The situation around dpkg-buildpackage and multiarch/cross-compile support is confusing. I now realize I had a wrong idea on what dh_auto_configure does internally. 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. Very true. 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. True. I guess just because dh does not export these variables, I thought dh does not behave correctly without these variables. But certainly, each debhelper scripts internally set these options without setting Makefile variables. I will update this shortly. Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763535: debmake should not encourage use of /usr/share/dpkg/default.mk
Hi, 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. Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763535: debmake should not encourage use of /usr/share/dpkg/default.mk
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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#763535: debmake should not encourage use of /usr/share/dpkg/default.mk
Hi, The more I look into this, I agree not to include DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/default.mk nor DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk 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: Reliance on exported environment flags Even if dpkg-buildpackage exports some variables, debian/rules should not rely on their presence and should instead use the respective inter‐ face to retrieve the needed values. Variables set by dpkg-architecture dpkg-architecture is called with the -a and -t parameters forwarded. Any variable that is output by its -s option is integrated in the build environment. The use of makefile inclusion may not be aesthetically good thing, but this seems to comply with the guidance in dpkg-buildpackage. Regards, Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763535: debmake should not encourage use of /usr/share/dpkg/default.mk
Hi, (It looks like this was not sent or lost in somewhere. Updating its content and sending this now.) Thanks for your useful feedback on how debmake should behave. On Tue, Sep 30, 2014 at 11:11:01AM -0700, Steve Langasek wrote: Package: debmake Version: 4.1.4-1 Severity: important I have just seen a package come through the Ubuntu NEW queue that used debmake to prepare it, and had the attached resulting debian/rules file. First, I think it's bad form for a tool like debmake to output commented-out examples in its production mode, because many people run the tool and then never remove the examples, contributing to cruft in the packages uploaded to the archive. 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. So I decided to do: All Tutorial lines are marked with ### for easy detection and text has been updated as: #!/usr/bin/make -f ### See debhelper(7) (uncomment to enable) ### This is a autogenerated template for debian/rules. ### You must remove unused comment lines before uploading to the archive. ### ### Output every command that modifies files on the build system. ###DH_VERBOSE = 1 ### ### See EXAMPLES in dpkg-buildflags(1) and read /usr/share/dpkg/* ###DPKG_EXPORT_BUILDFLAGS = 1 ###include /usr/share/dpkg/default.mk ### If uncommented, the above 2 lines set some useful variables for use ### in the debian/rules and ensures them to be the for both build cases: ### $ debian/rules build # quick build testing ### $ dpkg-buildpackage # proper package building ### These make it easy for the debugging but makes debian/rules unnecessarily ### complicated via the makefile inclusion mechanism. ### ### The compiler flags such as CFLAGS are always properly set by the ### dh command. So there is no need to set them this way. ### ### Please note some people consider it better practice to define ### arch-triplet etc. explicitly within debian/rules as needed without ### using this broad makefile inclusion mechanism. If you need to include ### some parts of makefile inclusion mechanism, copy relevant lines to ### debian/rules or include only individual makefile instead of default.mk. 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. 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. The template debian/copyright file generated by the current debmake is also very pedantic and verbose. The ftp-master has never complained missing entries for auto-generated permissive license files. Listing these pedantically actually increases the noise level for the license compatibility check. This is my another TODO, too. Second, /usr/share/dpkg/default.mk (like all make include files) is a horrible programming interface, reproducing everything that is wrong with cdbs in a standard tool. It is not required when using dh - dh makes the necessary calls to dpkg-buildflags and dpkg-architecture itself. *Please* fix debmake to not use such awful interfaces. My rationale to include /usr/share/dpkg/default.mk and export variables was to have the same build behavior for debian/rules and dpkg-buildpackage for east test building. This is good for debugging, as I thought. I did check if dh exports all such variables to the script in override target. Quick test results are: CFLAGS = yes DEB_HOST_MULTIARCH = no. I do not like CDBS since it is very convoluted. It is not easy to debug build script problem by divide-and-conquer. But default.mk is very simple and not so convoluted. It is also good source of code to copy from. Thus I updated text as I mentioned above. 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.) Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763535: debmake should not encourage use of /usr/share/dpkg/default.mk
Package: debmake Version: 4.1.4-1 Severity: important I have just seen a package come through the Ubuntu NEW queue that used debmake to prepare it, and had the attached resulting debian/rules file. First, I think it's bad form for a tool like debmake to output commented-out examples in its production mode, because many people run the tool and then never remove the examples, contributing to cruft in the packages uploaded to the archive. 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. Second, /usr/share/dpkg/default.mk (like all make include files) is a horrible programming interface, reproducing everything that is wrong with cdbs in a standard tool. It is not required when using dh - dh makes the necessary calls to dpkg-buildflags and dpkg-architecture itself. *Please* fix debmake to not use such awful interfaces. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org #!/usr/bin/make -f # See debhelper(7) (uncomment to enable) # output every command that modifies files on the build system. DH_VERBOSE = 1 # see EXAMPLES in dpkg-buildflags(1) and read /usr/share/dpkg/* DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/default.mk # see FEATURE AREAS in dpkg-buildflags(1) #export DEB_BUILD_MAINT_OPTIONS = hardening=+all # see ENVIRONMENT in dpkg-buildflags(1) # package maintainers to append CFLAGS #export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic # package maintainers to append LDFLAGS #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed # main packaging script based on dh7 syntax %: dh $@ --with click # debmake generated override targets # This is example for Cmake (See http://bugs.debian.org/641051 ) #override_dh_auto_configure: # dh_auto_configure -- \ # -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) signature.asc Description: Digital signature
