[Build-common-hackers] Ideas for the future of cdbs

Peter Eisentraut petere at debian.org
Mon May 18 15:57:56 UTC 2009

Since we took over the maintenance of cdbs from the forefathers a few years 
ago, we have been mostly bug fixing and doing the occasional advancement.  I 
have accumulated a few ideas over the years, and if there is enough interest 
among the maintainers, now may be the time to do some more sizeable 
architectural improvements and cleanups.

So here are some ideas:

* Require debhelper 7 and rely on its defaults.

One of the features of cdbs is that it supplies some dh_* commands with 
default arguments, e.g., dh_installchangelogs.  Now debhelper does the same, 
so we can relieve ourselves of that maintenance effort.

* only one dh_install call

Whack around debhelper.mk so we call dh_install only once, so --list-missing 
can be used.  Then kill util.mk. (bug #461368)

* a different compatibility scheme

The forefathers had created a version scheme like /usr/share/cdbs/*1*/rules 
..., but if you every actually want to change something incompatibly, you have 
to create a copy of the entire file or do some crazy make file inclusion, which 
is all very hard to maintain.  I imagine we take the idea from debhelper and 
just have a variable that says what the level is, e.g.,

include /usr/share/cdbs/filerighthere.mk

* Import class via variable

There is the ancient bug #202385 that says that instead of including a number 
of files, you set a variable to what you want and then include a common file, 

include /usr/share/cdbs/cdbs.mk

This would also get rid of the problems of the include order once and for all.

* Autodetection of rules and classes

For the most part, we can detect the rules and classes needed automatically, 
e.g., if you find a configure file, then use autotools. And everyone uses 
debhelper anyway, so we could make that the default.  So I imagine that most 
users would just have to write

include /usr/share/cdbs/cdbs.mk

And we regain some points in the quest for the shortest rules file. :)

* kill simple-patchsys.mk

The simple-patchsys is buggy, not robust, and a pain to maintain.  Most people 
would be better off with quilt.  We can pester people to stop using simple-
patchsys and eventually remove it.

* get CFLAGS from dpkg

This is currently under discussion, but dpkg nowadays supplies CFLAGS etc., so 
perhaps we shouldn't override that?

* man page

Many people complain that debhelper has man pages and cdbs doesn't.  So I 
think we could provide extracts from the manual as man pages.

* autotools-dev

We should consider making this a hard dependency, because many people forget 
it and then config.guess/sub doesn't get updated.

* throw out the Cpu/System replacement

The last blocking bug for that was just closed, so we can kill that obscure 

* eliminate control updates

I would like to get rid of that feature altogether, but I'm not sure what the 
full replacement could be.  Surely lintian can do most of the job, actually.

* version control

Unrelated really, but if other people are interested in switching from 
subversion to git, I could be interested.

* new version numbering scheme

something like 1.2.3, like debhelper


More information about the Build-common-hackers mailing list