On Wed, 28 Jul 2010 23:07:41 +0200, Jonas Smedegaard wrote: > >>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 :-/ No problem, I'm sure we can sort it out :) > >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! *hehe* > >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. Ok. We could also extend the table by a new column with/without backports.org. > 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). And backports.org currently has 7.4.11~bpo50+1 ... > >>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. I'm not surprised -- these are your own words quoted by me :) > But beware: this means > discouraging debhelper features introduced after (or unreliable > before) 7.0.16 for the next couple of years. Ack, that's why I wouldn't phrase it like that :) > >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. Well, catering for individual backporting strategies seems a bit difficult to me. > >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. Agreed, subject adjusted. > 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. Thanks :) 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 #272: Netscape has crashed
Attachment:
signature.asc
Description: Digital signature