uploaded first pkg: pd-motex

[Reinhard Tartler]

Aah, finally a new round of cdbs vs. dh bashing, we didn't have enough
of that at debconf 10 ;-)

On Fri, Aug 13, 2010 at 10:40:08 (CEST), Jonas Smedegaard wrote:

> On Thu, Aug 12, 2010 at 11:43:51PM +0200, Benjamin Drung wrote:
>>Am Donnerstag, den 12.08.2010, 23:38 +0200 schrieb Jonas Smedegaard:
>>> [1] or agree to repackage using cdbs - I just won't you to get the
>>> impression that I lured you into this: most people in the multimedia
>>> team are fine with - yeah, even prefer - short-form dh, it is just me
>>> being obnoxious.
>>
>> I prefer dh over cdbs over long debhelper form. Are there any
>> technical reasons for not using dh?
>
> Good question. Thanks for asking!
>
> 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. cdbs itself does not seem to be available on backports.org at
all. 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.

> 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

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.

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.

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

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

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.


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