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