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. -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
