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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
