On Wed, Jul 28, 2010 at 02:58:09PM -0400, gregor herrmann wrote:
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.)
Oh, so your post was mostly about documenting simplification (in build-dependencies) and I now add complication (in backporting support). Sorry for that :-/
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.
As I hinted below, lives of both you and backporters would be easier if you saw the light of CDBS: Perl libraries in a 3-4 lines long rules file have been possible since 2004 with CDBS, so no backporting problems there!
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 :))
As I see it, the following degrees of care for backporting exist: a) Support oldstable (until dropped) b) Support oldstable (until dropped) + other backporting mixture c) Support stable d) Support stable + other backporting mixture e) No backporting support As Etch has been dropped by now, classes a) - c) are currently equal.A package build-depending on debhelper 7.0.15 has class a) backporting support until Lenny is dropped.
A package build-depending on debhelper 7.0.16 or newer has class d) backporting support.
A package build-depending on debhelper 7.4.11 or newer has class e) backporting support (until a newer debhelper is backported).
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.
Expressed like that I fully agree. But beware: this means discouraging debhelper features introduced after (or unreliable before) 7.0.16 for the next couple of years.
That is much more conservative than in reality you've generally wanted for the short-form dh feature introduced in debhelper 7.0 and still getting more and more extensions.
Of course such phrasing do not _mandate_ being conservative, just recommend it. Time will tell if in reality it then has any real affect :-P
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.
I recommend against writing guidelines tied to backports.org. Backporting is more than backports.org (e.g. I apply different - IMO stricter - dependency rules for my backporting efforts), and that repository is by design a moving target.
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).
Yes. Let's let this subthread be about backporting-friendlines.In other words, please everyone, comment on the original post by Gregor regarding build-dependency simplifications, so that simpler proposal does not get stalled/swamped by any discussions here.
Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: Digital signature