[Build-common-hackers] Ideas for the future of cdbs
dr at jones.dk
Mon May 18 19:12:25 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, May 18, 2009 at 06:57:56PM +0300, Peter Eisentraut wrote:
>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.
great that you bring it up!
>* 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.
I very much like that CDBS is not an extension to debhelper but can be
used either as a replacement or an addition. Concretely, I sometimes
partly convert to CDBS, while leaving other parts as-is. This proposed
change would force me to always use CDBS for debhelper if I wanted to
use CDBS for any other features.
It makes perfect sense, however, to internally cleanup the debhelper.mk
snippet. Which leads to another topic for discussion here:
* Structured feature "aging"
Let's cleanup features that are no longer relevant - but not cleanup too
We should support features in stable Debian (e.g. DH6), to not break on
partly upgraded systems.
If not too complex for us to maintain, we should also features in
oldstable (e.g. DH5), to ease backporting packages that use CDBS.
Before removing, we should first deprecate, e.g. warn that the feature
is going away. Ideally we should warn for a full release cycle, then
remove. For features only exposed to unstable/testing we might allow
quicker aging, but even then we should be careful.
(whoa, my argumentation turn more and more into _preservation_ than
_aging_ - probably due to the frustrations I had when discovering how
badly Python v1 support was treated when Python v2 was implemented on
top of it - not that I am complainin, just to say that it _was_
frustrating to deal with the results of that).
>* 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)
When there is a bugreport then let's discuss it there rather than here!
>* 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
Debhelper is written in a language much easier to subclass, and handles
a range of compatibility levels from same files, with backwards
I would want to define some stricter rules for cdbs v2 and slowly
provide snippets that obey them, while still keeping the old ones
around, and without needing to clutter the new ones with problematic
As an example, I would like consistency in variables applied to all
packages, specific ones, and applied by default. Currently pkg-specific
variables are sometimes applied in addition to non-pkg ones and
sometimes as override. Providing backwards-compatibility would make it
_very_ difficult to maintain all the many many variable expansions.
>* 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.,
>This would also get rid of the problems of the include order once and
I dislike such added indirection.
I see no problem in providing a cdbs.mk snippet (that I could then
choose to avoid), but having it mandatory, as would be needed for it to
solve other issues, is bad IMHO.
I like the freedom of ordering, and believe - as I've written before in
bugreports - that the proper approach to the ordering problem is to a)
avoid e.g. ifeq constructs and b) implement verifications and emit
warnings or errors when outright broken ordering is discovered.
>* 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
>And we regain some points in the quest for the shortest rules file. :)
Feel free to implement such cdbs.mk snippet - or make a draft and file a
wishlist bugreport where we can discuss implementation details. I see
no need for large coordination work there.
Only if such interface was to _replace_ existing atomic snippets, but I
disagree with that, as mentioned above.
>* 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.
I fully agree: I see no benefit at all theses days for keeping it alive.
Except, as I described further up, that I believe we should first
deprecate it for a full release cycle before finally dropping it.
>* get CFLAGS from dpkg
>This is currently under discussion, but dpkg nowadays supplies CFLAGS
>etc., so perhaps we shouldn't override that?
Please let's limit discussion here to those bugs in relation to other
isues raised here (e.g. if we should do it in CDBS v1 at all, and how to
deal with backwards compatibility), and discuss details at the
bugreports itself: #523642 and #521872
I see two questions here:
a) offer optional different behaviour (e.g. through flag)
b) change default behaviour
I believe we should *not* change the default behaviour in CDBS v1.
I suggest we provide a flag to switch behaviour, and then when some day
we implement CDBS v2 we can flip default setting of that flag.
>* 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.
I see no problem in accepting manpages when offered.
I do see a problem in mandating manpages, however. I still have a bunch
of locally maintained snippets and snippet enhancements that is not
integrated mainly due to the "requirement" of documentation.
(I put "requirement" in quotes, as really we decide that on our own, but
historically my changes was rejected some years ago with the reasoning
that they did not come with updates to the docbook documentation.)
>We should consider making this a hard dependency, because many people
>forget it and then config.guess/sub doesn't get updated.
Please let's discuss this in the related bugreport instead of here.
I remember it was discussed pretty recently, but fail to locate the
bugreport now. If it hasn't been filed as a bugreport, then please do -
I see no reasosn to discuss it here (I suspect this discussion can
become complex enough without details of each issue).
>* throw out the Cpu/System replacement
>The last blocking bug for that was just closed, so we can kill that obscure
Please discuss that at bug#473599 - I don't see how it affects other
issues raised here, so see no reason discussing it at the meta level.
>* 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
I strongly disagree.
Lintian cannot do control updates at all, only inform about them.
I use CDBS auto-updating for all the 80+ packages that I participate in
maintaining. I have even extended it to also handle
non-build-dependencies, allowing for comments (e.g. "keep until
Lenny+1") and expansion (e.g. libboost$(boost_ver)-dev ).
As a related thing, I would like the name of the infile to be
configurable, to allow reimplementing Cpu/System support and more using
xcontrol, which also uses the filename control.in.
Perhaps if I am the one one using control file auto-updating, we should
not discuss improvements here, just agree to disagree, and if I want
flexible infile names badly enough then I go implement it myself?
>* version control
>Unrelated really, but if other people are interested in switching from
>subversion to git, I could be interested.
I would be _very_ interested in that. I propose using the collab-maint
group rather than our own: I see no need for protection against our peer
developers, and if things go sour it is easy to revert changes.
I volunteer to do the transition. :-)
>* new version numbering scheme
>something like 1.2.3, like debhelper
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Build-common-hackers