On Sat, Aug 14, 2010 at 12:13:52PM +0200, Reinhard Tartler wrote:
On Fri, Aug 13, 2010 at 21:15:26 (CEST), Jonas Smedegaard wrote:On Fri, Aug 13, 2010 at 05:20:45PM +0200, Reinhard Tartler wrote:On Fri, Aug 13, 2010 at 10:40:08 (CEST), Jonas Smedegaard wrote:CDBS is more backports-friendly (beyond backports.org too!).It is only more backports-friendly if you also always backport the very latest version of cdbs, which does not match my definition of backport' at all.You are completely right that ideal backportability means no dependency on other backports. Which is the reason I counted backports.org out!These two sentences doesn't make sense to me together. Either you or I have misunderstood backports.org. That repo does not build by default against packages also in backports.org, unless explicitly requested by the build-depends, exactly like experimental is currently handled.
Official Debian packages are compiled in a Debian unstable environment.A "backport" to me is the task of recompiling package(s) in an older Pure Debian environment, either officially released or a snapshot of a staging area. Examples of backporting targets are "Debian/Lenny", "Debian Etch" and "Debian testing as of noon 2010-08-14".
Recompiling packages for something else than an older Debian environment is "sideporting" to me. Examples of sideports are "Ubuntu Jaunty", "Skolelinux Etch" and "the mixture of Debian Lenny + Lenny branch of backports.org as of noon 2010-08-14".
Packages not requiring things recently introduced into Debian I call "backports-friendly". The further back the requirements are satisfied, the more backports-friendly that particular package is.
It seems that your use of the term "bacporting" is what I would describe as "sideporting to the mixture of Debian stable + a few packages cherry-picked from stable branch of backports.org as of now".
With your use of the term (if I got it correctly) we might reach a different conclusion regarding which packages are backport-friendly, depending on which dependencies happens to be offered that particular day at backports.org. Right?
And yes, CDBS is *genuinely* backportable more than short-form dh!if your copy of cdbs is recent enough, sure. but the same argument counts for dh7 as well, which has a 7.0.15 in stable. The only thing that doesn't work in stable by itself is the quilt series trick.
If the cdbs package in the target build environment do not satisfy requirements of the package being built, then that package is less backport-friendly as either the packaging needs some hacking or a newer cdbs needs to be backported (by yourself or someone else via e.g. backports.org). However done the target environment becomes slightly "contaminated" thus slightly less reliable.
jackd2 and bitmeter use CDBS and are backport-friendly: They compile in plain Lenny without contaminating it with any other bacported packages, neither locally built nor e.g. backports.org.
calf use CDBS and is less backport-friendly: it requires a recent cdbs. ffmpeg use short-form dh and is backport-friendly: it uses only features also available in stable.
Bitmeter is *more* backport-friendly than ffmpeg because its build-dependencies are (mostly if not fully) satisfied even in oldstable.
You may judge oldstable as obsolete for your purposes. So do I these days, but I did not 6 months ago, and I most likely will not render Lenny obsolete as soon as it enters oldstable but only some time after that. The very aim (for me, at least) of backport-friendliness is to ease use in unusual environments.
1) Demonstrating "a case" does not undermine "more backportable".sure, but already this thread gives me enough reason to not even try this further.
So you do not disagree that CDBS is "more backportable" but dislike it for other reasons. Fair enough: Benjamin asked about reasons for using CDBS over short-form dh - not reasons to avoid it.
2) Releasing testing packages as stable is flawed: Ubuntu is flawed!because they want to build packages that require newer CDBS? come on, they just take what's available in unstable. OK, they switched now to testing, IIRC, but now we're really offtopic.
No, because that particular CDBS release was broken. Earlier versions worked, and later versions worked.
The case you referred to concerned a FTBFS on Ubuntu due to a broken release of CDBS on that system. Same things occur in Debian if not properly tracking the branch used. This is not tied to CDBS at all.
I can elaborate more if you do not understand my point. Ubuntu bashing is off-topic, agreed.
With "more backportable" I mean to say that CDBS in more cases than short-form dh is it possible to compile packages in an older Debian environment either a) as-is or b) with minor adjustments - e.g. changing or removing build-dependencies."more cases"? Sorry, this does not match my experiences with cdbs so far.
I find that a pretty weak argument, especially taiored with my knowledge of you as packaging for Ubuntu (as well as Debian) and your only example provided was due to Ubuntu shipping a cdbs release considered broken in Debian.
debhelper maintains a history of very stable interfaces, called compat levels. I'd really love to see something similar to cdbs. And this verystrict commitment to stable interfaces and semantics help
a lot for backporting packages.
Clearly defining when packaging what new funky features is used helps *hacking* efforts of less backport-friendly packages.
What helps even more, however, is that hacking is not needed. Clear ABI versioning does not help here, but sticking to backwards-compatible parts of an ABI does.
For debhelper the main problem for backportability have recently been the very use of short-form dh. This is arguably historic, as stable contains the initial basic implementation of this new feature. Currently - for backports to Debian stable - the problem then is the use of extensions to short-form dh which requires e.g. debhelper 7.2.
Congratulations: You made me discuss debhelper. I tried to avoid it, but there you go: let the flames flow.
Oh, and if you are lazy (or don't want to touch those weird CDBS-using debian/control files) then CDBS itself is backportable as its dependencies is fulfilled even on Etch (and, if I recall correctly, Sarge too!). Backporting a recent debhelper requires backporting dpkg which I wouldn't dare do...as already pointed, hardly anyone cares about oldstable (or earlier) anymore. What I care much more would be to backport to previous ubuntu releases, particularily those that ship "broken" releases of cdbs.needless to say that dh packages make much fewer problems there...
I wholeheartedly agree with you that debhelper-only packaging is not affected by systems shipping with a broken release of cdbs.
Halleluja!
moreover, scanning for new upstream releases or checking for license problems is hardy a practical concern when backporting packages. Therefore, I think that shouldn't be in debian/rules, instead it should focus on building packages.
CDBS being more backport-friendly is *one* argument out of several. Yes, I agree with you that not all features of CDBS are relevant when backporting. I do claim that all of them are relevant for packaging!
CDBS is written in make (short-form dh somewhat reinvents make in Perl)it reinvents much logic that cdbs chooses to implement in make, but also most of cdbs, espc. the tasks that you indicated above, don't really benefit from the properties of the make language.I fail to see how your argument here is different from your argument further up (which I disagree with).You claimed that "short-form dh somewhat reinvents make in Perl", which I don't follow.My argument is that debian/rules is a build script. The feature that makes make unique is its dependency resolution feature, and this is often not that essential for building software packages. For this reason, I really disagree with the "reinventing" part of your claim.
I disagree that the only benefit of Make is its dependency resolution.
And now for context of everyone that has not attended Jonas and my real life flamefest at debconf 10, yes, Jonas and I had (at least one?) long real-life conversation about cdbs. It's not that I really disklike it or something, au contraire, I do think that cdbs does have benefit for some groups of packages. E.g. I know that the gnome and kde package consolidate a lot of build logic into cdbs, and this really makes sense to me.I am unaware of CDBS being aggressively used by the GNOME or KDE teams, or any other teams in particular for that matter.Might be stronger in ubuntu than in debian, I didn't check that myself, though.
You could try provide some examples...I suspect that you confuse "using cdbs" with "including a shared make snippet into the rules file".
- Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
