Scott Howard wrote: > From the debhelper manpage > > "Unless otherwise indicated, all debhelper documentation assumes that > you are using the most recent compatibility level, and in most cases > does not indicate if the behavior is different in an earlier > compatibility level, so if you are not using the most recent > compatibility level, you're advised to read below for notes about what > is different in earlier compatibility levels." This is overstated; while it's quite likely the documentation for a particular command will fail to mention some change made in a recent compat level, the compat level is always mentioned when some incompatible change or new feature is actually properly documented. :P > and > "v8 This is the recommended mode of operation." This qualification is there mostly to avoid people using v9 before it's complete; the only non-recommended compat levels are v4 and below, which are deprecated. As a point of comparison, the compat histogram for packages I co-maintain is: 124 7 6 5 3 8 2 4 1 9 1 6 Thomas Goirand wrote: > I believe that CDBS/dh is hiding what's necessary to > do a good packaging, and is calling too many unnecessary helpers, > which slows down the build process. Bear in mind that CPUs have doubled in speed something like 7 times since debhelper was originally written -- and it was written from the beginning to be not annoyingly slow when every command was put in the rules file. There have also been some siginficant speed improvements made for the dh case. A rules file for a multiarch packages using dh is likely to be faster than one hand-written. I suspect this may come down to phycology at this point; we see a lot of commands running and feel the build took longer. Of course there is still room for improvement -- it's been suggested that dh could run many commands in parallel.. > Also, with dh_override_*, if you > have a lot of them, it soon becomes unreadable. That's only my opinion To the contrary, I find that it exposes the essence of what makes a package different, and even an example such as the following does not seem hard to read, because there are no complex interrelationships between the override targets. override_dh_auto_install: $(MAKE) prefix=`pwd`/debian/debconf-utils install-utils $(MAKE) prefix=`pwd`/debian/debconf-i18n install-i18n $(MAKE) prefix=`pwd`/debian/debconf install-rest # Run dh_link earlier so that it has an opportunity to link documentation # directories. override_dh_installdocs: dh_link dh_installdocs override_dh_installdebconf: # Don't modify postrm, I purge differently than normal packages # using me dh_installdebconf -n override_dh_install: dh_install cp debian/apt.conf debian/debconf/etc/apt/apt.conf.d/70debconf cp bash_completion debian/debconf/etc/bash_completion.d/debconf override_dh_installchangelogs: # Changelog reduction hack for debconf. Only include top 100 entries. perl -ne '$$c++ if /^debconf /; last if $$c > 100 ; print $$_' \ < debian/changelog > debian/debconf.changelog dh_installchangelogs override_dh_compress: dh_compress -X demo.templates -X tutorial.templates -- see shy jo
Attachment:
signature.asc
Description: Digital signature