[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CDBS and dh_install

On Fri, Jun 09, 2006 at 02:02:48PM -0500, Manoj Srivastava wrote:

> >> This is my opinion and others will disagree:
> >> Please don't. CDBS is a major pain to use for those who didn't
> >> (co-)author it. It's just too much about obfuscation.

> > This is also my impression. CDBS might be nice to automate the task
> > "make a .deb out of this Gnome source", but imho it completely fails
> > when you want to deviate from the "standard" in any way.

>         I am surprised to hear you say so, since CDBS is one of the
>  most configurable build systems out there. You can add commands to
>  any phase of the build, by just adding targets/dependencies/variables. 

>         Off hand, I would say that the cdbs approach is as flexible as
>  any one might find.

Flexible, yes.  Accessible?

> > CDBS hides what it's going on while building the package. It is very 
> > hard to see what it does, and if you are a newcomer, it is next to
> > impossible to actually learn anything from using it. (And the syntax
> > is very ugly.)

>         Very subjective. I mean, heavens, cdbs is just a make file,
>  and we all have some need to know how make works, as opposed to
>  learning python/Perl/ruby or whatever other languages a helper
>  package may be written in.

>         I haven't really found the CDBS makefiles very hard to follow,
>  but that again is subjective.

Let's compare debhelper to cdbs.

When using debhelper, you (typically) have a single debian/rules makefile
which lists out all the commands that are invoked for building your package;
each of those commands primarily uses the contents of other files in debian/
as input.  If you have questions about what any one of those lines does,
there is a manpage that you can refer to.  Thus, a debhelper-based
debian/rules is composed of discrete units, each of which can be understood
separately through the *documentation*, and the maintainer held to account
if the behavior doesn't match the documentation, without any requirement
that the user understand the implementation language of perl.

In contrast, almost all of cdbs is stashed away in /usr/share/cdbs/; almost
none of what it does is inspectible by looking at the debian/rules and using
those lines as hooks into the documentation.  There is
/usr/share/doc/cdbs/cdbs-doc.html, which documents many of the common
variables one may wish to use, but there is no concise description of what
the cdbs rules *themselves* do.  It's nice to know that you can supplement
the standard rules with additional double-colon rules, but you're basically
expected to trust that the default rules Do The Right Thing -- if you find
that a cdbs rule does the wrong thing, your only recourses are to either try
to fix up the output after the fact (assuming the Wrong Thing isn't a fatal
failure), or to not include that problematic cdbs class and reimplement the
rules by hand.  Oh, and to top it off, almost all cdbs packages include
/usr/share/cdbs/1/rules/debhelper.mk anyway, so they're still *using*
debhelper behind the scenes. :)  Just not in a form that leaves the package
maintainer any control over the process beyond that granted them by the
cdbs maintainers...

And btw, last I looked at the cdbs makefiles, they were among the most
arcane uses of make syntax that I'd ever seen.  Arguing that cdbs is good
because make is a least common denominator language in Debian is like
arguing that we should do GRs in iambic pentameter because English is the
lingua franca. :)

> > Again, I'm fine if you use CDBS for your package, but please never
> > recommend it to any new maintainer.

>         Why would this not apply to any other helper packages as well?

Is it no longer a requirement of NM that applicants demonstrate themselves
capable of putting together a source package without the use of rules

There are also pretty significant differences in the design goals of
debhelper and cdbs, differences which I believe have a major impact on the
ability of maintainers to understand their own packages and on the
respective helper-induced build failure rates of the two.  I think these are
very pertinent reasons not to recommend cdbs to novice maintainers.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: