checksumming debian/rules (was: Re: Minutes from the pkg-perl meeting on 26th of July)

[Tim Retout <tim@retout.co.uk>]

On Thu, 2009-07-30 at 13:52 +0300, Damyan Ivanov wrote:
>  * auto-updating d/rules after checksumming:
>    - dh-make-perl to create d/rules with the checksum tag
>    - dh-make-perl to update d/rules only if its checksum matches 
>      a known generated one
>    - tim takes care of this

I've been thinking about this.  Updating debian/rules when the checksum
matches a known generated one could be done by dh-make-perl without
needing to add a checksum tag in the file itself.  Indeed, if we
checksum the file and then add a tag, we will have to handle the fact
that the checksum will change!  We would have to strip out the tag again
before calculating the checksum.

Looking back at the notes from Argentina, the original idea was to
include the checksum of the rules /template/ in the top of debian/rules.
But this idea was before dh7; I think going through the 1300 existing
packages and adding tags to the top is far too much effort, and
unnecessary.  And once the rules file is customised, I don't think a
migration can happen automatically; we will always need a manual
inspection in this case.  (Unless we take a diff and try applying
it...?)

So first, what I have done is to build a tree of sha1sums of the
existing debian/rules files, using a bash one-liner like this:

mkdir ../hashes
sha1sum */debian/rules | while read line; do hash=`echo $line | cut -d' ' -f1`; \
   file=`echo $line | cut -d ' ' -f3`; cp -n $file ../hashes/$hash; done

And I built some other files to show how frequently-used each version of
debian/rules was, and to provide a mapping of sha1sum back to the
packages which use each version.  Note that running these commands is
very quick indeed, even over the whole of svn trunk.

In my copy of trunk from a few days ago, there are 765 different
debian/rules files.  Some of these are quite similar (just whitespace
differences)... but a lot are obviously just customized, or previous
standard versions.  The most popular rules file is used in just 112
packages.

You can use 'wc -l * | sort -n' in the hashes directory to show how long
each rules file is; the longest two are 248 and 252 lines (both using
yada).

Anyway, it's still possible to hack dh-make-perl to update rules files
automatically, but given some of the numbers above, I think it might be
better to just use checksums to do mass updates outside of dh-make-perl?
It's still possible to do, of course, but there are 765 checksums to
study to see whether they can be updated automatically.

In my opinion, it's more cost-effective to migrate to three line dh7
files (with and without quilt) first, and then hack dh-make-perl if we
ever migrate away from that (assuming we can get 1000+ packages using
two standard rules files).  Even then, mass commits are easier, assuming
we can test the changes properly.

-- 
Tim Retout <tim@retout.co.uk>