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.
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:
> >>>  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.
pkg-multimedia-maintainers mailing list