On Fri, Aug 13, 2010 at 05:20:45PM +0200, Reinhard Tartler wrote:
Aah, finally a new round of cdbs vs. dh bashing, we didn't have enough of that at debconf 10 ;-)
The best way to keep a thread alive(!) is to feed it new arguments, as you do below.
I honestly tried to not do side-by-side comparison between dh7 and CDBS, but stick to facts about CDBS itself.
I shall try my best to keep at that, and leave it to others throwing questions or counter-arguments to decide if this thread should be kept alive or not.
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!
And yes, CDBS is *genuinely* backportable more than short-form dh!
cdbs itself does not seem to be available on backports.org at all.
I dislike backports.org so do not contribute to that myself.Others apperently don't either - most likely due to it not being important: See above!
Moreover, These are the used versions in ubuntu: cdbs | 0.4.51ubuntu1 | hardy | source, all cdbs | 0.4.52ubuntu18 | jaunty | source, all cdbs | 0.4.59ubuntu4 | karmic | source, all cdbs | 0.4.62+nmu1ubuntu9 | lucid | source, all cdbs | 0.4.83ubuntu1 | maverick | source, allAnd I've already shown you a case where a package failed to build with lucid's cdbs and you just told me that ubuntu where shipping broken cdbs package. Sorry, that does not help me at all with backporting packages.
1) Demonstrating "a case" does not undermine "more backportable". 2) Releasing testing packages as stable is flawed: Ubuntu is flawed!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.
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...
If all of that "does not help [you] at all" then too bad: I dare say that any narrower definition of "more backportable" won't get you very far with most backporting efforts.
CDBS provides routines to fetch and repackage upstream tarballsCDBS provides routines to track copyright and licensing info of sources.What is the technical reasoning for needing to integrate these logics into debian/rules? I think as developer I'm much more flexible if they are implemented in seperate, reusable stand-alone tools. This way:a) more packages would use the same code to do these tasks b) these helper tools could be maintained and backported independently of cdbs c) they have really nothing to do with the act of building packages, but are more general maintenance tasks
Yes, and this is a noble goal for the future. As I already told you at debconf I plan to do that for the copyright & licensing part.
I think this is the thing that makes me dislike cdbs, too many maintenance tasks are integrated into debian/rules and therefore, are implemented in make, which is a fine language that I also like to program with, but for these tasks, 'make' doesn't really help much.
I totally agree with you that make is not ideal for all of this. This is the reason copyright & licensing code is implemented in Perl.Make is powerful to resolve chains of smaller rules and interdependencies betwen them, which is quite useful for other parts like the get-orig-source target. When uscan perhaps matures to contain more of these routines then newer releases of CDBS can embrace that - while stil being backports-frindly :-)
Jonas, would it be an option to you to implement them in a language other than make? Ideally, we could try (again) to push at least some of these tasks into the devscripts package, which is more the place I think they belong to.
As mentioned above (and partly told to you in person already at Debconf) this is slowly happening already.
And really I feel that this is sliding far quite away from the original question: "Are there any technical reasons for not using dh [but stick with CDBS]?" as asked by Benjamin.
CDBS is less invasive - e.g. can be used with manually run dh_* commandsas indicated above, the integration of all kinds of maintenance tasks fits my understanding of "more invasive", because more unrelated tasks are implemented into a single program: debian/rules.
Ok, so you interpret the term "invasive" differently than me. I believe I did later elaborate on the intended meaning of above phrase, and if this is more than a word game, then aim at that: please shoot the messenger, not the message ;-)
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).
I do feel that my argument is different is different from my other original arguments. I can clarify this if anyone wants, but hesitate to not risk repeating myself or spawning too much new threads...
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.
Phew - hope I did not stir up too many new seeds for further discussion. Regards, - Jonas I may change my mind regarding backports.org now that I (at a debian-mm BoF last week) learned how it might be more sanely constructed than I had (wrongly or through earlier design) had understood.
 At the get-orig-source target I actually cheat at the moment and embed a shell script instead of more structured make usage.
 The trailing part of that pseudo-quote is my fabrication, but Benjamin clarified that he favored CDBS over the older long-form dh_*.
-- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list firstname.lastname@example.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers