On Wed, 28 Jul 2010 17:17:10 +0200, Jonas Smedegaard wrote: > >* debhelper compat level 8 (still experimental) prefers Module::Build > > over EUMM. We've traditionally expressed a build dependency on M::B > > by using "perl (>= 5.10) | libmodule-build-perl". > > When we want to change to compat 8 we either need to add this all > > over the place or accept the fact that the package won't build in > > oldstable (perl 5.8). - Several people on IRC said they were fine > > with dropping support for etch at this point in time. > I wholeheartedly welcome such policy regarding support for backporting. Great! > Beware, however, that it also affects debhelper compatibility level! True, but as noted above: The trigger for the discussions and this draft was the preparation for debhelper 8 :) (And the aim was to write down when we drop alternative dependencies or versions from dependencies instead of scratching our beards on IRC in a small group every now and then.) > In the past, I have discretely cursed the aggressive use of > debhelper 7, as I needed a bunch of Perl libraries backported to > Etch[1] and had to repackage completely using CDBS. I see your point; IMO supporting backports is always a balance between minimizing work for us and for potential backporters. I'm all for helping backporters, as long is the "costs" for us are reasonable (yes, "reasonable" is both vague and subjective). And since debhelper 7 makes life much easier for us I tend to vote for making _our_ lifes easier in this case. > Contrary to debhelper, CDBS-based packages can in most cases be > backported as-is, and in the few cases where very recent CDBS > features are required, CDBS itself is easy to backport (unlike > debhelper). There's a rather current version of debhelper in lenny-backports (yes, that's not etch, but etch is end-of-lifed anyway :)) > I therefore recommend to include in backport-support recommendations > to only bump debhelper compat level when really needed, and whenever > possible stick to the compat level supported in oldstable. What I can imagine is - thinking about when to switch to a new debhelper version in the future (e.g. waiting for a debhelper $stable-backport); - trying to avoid debhlper features that are only "nice" but not needed if the version in $stable-backports doesn't support them. That would need another discussion and, (if we find some guidelines,) a separate section in our policy since my quick draft only talks about (build) dependencies (alternatives and versions). Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `- BOFH excuse #260: We're upgrading /dev/null
Attachment:
signature.asc
Description: Digital signature