uploaded first pkg: pd-motex

[Reinhard Tartler]

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:
>>
>> 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!

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.

> 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.

>>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".

sure, but already this thread gives me enough reason to not even try
this further.

>    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.

> 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.

debhelper maintains a history of very stable interfaces, called compat
levels. I'd really love to see something similar to cdbs. And this very
strict commitment to stable interfaces and semantics help a lot for
backporting packages.

> 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...

> 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.

yes, that is the bottom line I get from this thread: Your ideas of
backporting and stable interfaces clearly don't match mine.

>
>>> 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.

Right! And I'm really looking forward to that! Thanks!

>> 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 :-)

Indeed!

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 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 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.

Might be stronger in ubuntu than in debian, I didn't check that myself, though.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4