uploaded first pkg: pd-motex

[Hans-Christoph Steiner]

Now that there is a separate thread on cdbs vs dh, perhaps someone could
give me some feedback on my pd-motex package which happens to use dh.
I'm ready to fix whatever needs fixing.

.hc

On Fri, 2010-08-13 at 17:20 +0200, Reinhard Tartler wrote:
> 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.
> 
>