[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.,
CDBS_COMPAT = 2
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,
e.g.,
CDBS_MODULES=debhelper,autotools,simple-patchsys
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
feature.
* 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
Comments?
More information about the Build-common-hackers
mailing list