The point of debian/compat (was: what compat level for debhelper in jaunty?)

[Lars Wirzenius]

ke, 2008-12-17 kello 15:08 +0100, Morten Kjeldgaard kirjoitti:
> Btw, I'd like if someone could explain what good debian/compat is, now
> that there are versioned depends and e.g. dh_lintian requires debhelper
> >= 6.0.7~ and dh_icons requires >= 5.0.51~. In these cases, compat could
> be correct and the build would still not work if the microversion of
> debhelper was not up to specifications. Couldn't debian/compat be dropped?

(Long, rambling reply, sorry.)

It's my understanding that debian/compat controls how debhelper works:
backwards incompatible behavior changes require debian/compat to be
sufficiently new for the new behavior to happen. This prevents existing
packages from being broken by a new version of debhelper. In other
words, debian/compat is how the package declares to debhelper it is
ready for all the stuff at a particular compatibility level. See
debhelper(7), subsection "Debhelper compatibility levels".

As an example (from the manpage), at compatibility level 5
dh_installdocs no longer installs empty files. While this is almost
certainly the right thing to do, it is conceivable that an existing
package might install empty files on purpose[1], and would break if they
were no longer installed. When the packager has verified that this is
not the case, they can increase debian/compat from 4 to 5 and get the
benefit from the new behavior.

I've always found this to be one of the ingenious parts of debhelper,
and Joey Hess's devotion to backwards compatibility is probably one of
the reasons most packages use debhelper.

debian/compat would be possible to replace with versioned Build-Depends.
If debhelper had not been implemented before Build-Depends existed in
Debian, that might be the mechanism. It would make it harder to figure
out the compatibility level, though: instead of just reading a file,
you'd have to parse debian/control, parse the header, and finally also
parse the version number.

As you point out, debian/compat is embedded in the source package and is
not verified when build dependencies are evaluated. As a result, we may
need to specify both debian/compat and a versioned build dependency,
probably resulting in the last simple situation. 

However, to drop debian/compat, you'd have to transition all
debhelper-using packages and that's quite a bit of work, without giving
particularly much direct benefit. Given the strict backwards compatible
attitude of debhelper, the transition would have to continue until every
package relying on debian/compat was fixed. The transition would also
have to continue until there was clearly no need to backport the new
debhelper to a version of Debian or Ubuntu (or derivative) that has
packages that rely on debian/compat to build correctly. Given the long
support times of Ubuntu LTS releases, and all Debian releases, that's
quite a long time.



[1] Don't ask me how. Perhaps a later part of debian/rules explicitly
deletes them and breaks if they're not there. The point is: debhelper
has changed existing behavior and debian/compat is there to protect
existing packages just in case.