Re: CDBS and dh_install
On Fri, Jun 09, 2006, Steve Langasek wrote:
> 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.
You are looking at the individual dh_* commands, but:
- the precise list of debhelper calls varies from package to package,
there's nothing standard or documented in this
- the order of the debhelper calls varies from package to package
Compare with CDBS where the list of debhelper calls has some order
constraints and where the list itself can evolve: introduction of
dh_gconf in the rules used by GNOME packages is only a matter of adding
the call to the relevant CDBS file, not to each individual package.
I agree that it's a nice feature to be able to say dh_install conforms
to its documentation, yet the same feature is available in CDBS which
calls dh_install: the precise dh_install call will happen from CDBS
instead of directly from your debian/rules, but you have the same
documentation, and interface to write your debian/*.install files.
> 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.
Agreed, documentation is a bit lacking and could be improved. More
importantly, the interface is not as clearly defined as a command call,
because Makefiles allow much more. I can't imagine what to put in a
simple-patchsys.mk man page, or it would be as long as the original
makefile.
> 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...
But these are great features: not only does it uses debhelper behind
the scenes and let's you store meta-information in debian/* files (such
as the examples in debian/package.examples), it will also spare you the
time of writing and parsing a long list of dh_* calls that is present
in pure "debhelper" packages. Yes, you loose some control, but there
are often ways to achieve what you need to.
Besides, I don't think anyone will step up to claim that CDBS is good
for all packages in Debian. The very simple tasks that debhelper ships
make it an omniscious build-dep, while the more high-level tasks of
CDBS won't fit certain packages, for example they are particularly not
suited to multiple builds of the same source.
> And btw, last I looked at the cdbs makefiles, they were among the most
> arcane uses of make syntax that I'd ever seen.
Still, each time I grepped them for the override I was looking for, it
worked. :)
> 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.
It factors code together, exactly as debhelper aims at, except it
happens on a higher level with CDBS.
After all, I could claim that everyone knows the interface to cp and
mv, and use them instead of debhelper.
> 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.
Yes, I 100% agree with you. Would I be evaluating an applicant, I
wouldn't like him to prepare a new source package in CDBS. (But I
wouldn't request to build a .deb with ar either.)
Is Debhelper our C and CDBS our C++?
--
Loïc Minier <lool@dooz.org>
Reply to: