uploaded first pkg: pd-motex

Fri Aug 13 19:15:26 UTC 2010

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[1] 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, all
>
>And 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 tarballs
>>
>> CDBS 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[2].  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[3].

>> CDBS is less invasive - e.g. can be used with manually run dh_* commands
>
>as 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

[1] 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.

[2] At the get-orig-source target I actually cheat at the moment and 
embed a shell script instead of more structured make usage.

[3] 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100813/00e1b707/attachment.pgp>