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 helpers? 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