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

Mon May 18 19:12:25 UTC 2009

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

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 
aggressively either.

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
>include /usr/share/cdbs/filerighthere.mk

I disagree.

Debhelper is written in a language much easier to subclass, and handles 
a range of compatibility levels from same files, with backwards 
compatibility.

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 
backwards compatilibity.

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.,
>
>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.

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
>
>include /usr/share/cdbs/cdbs.mk
>
>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.)

>* autotools-dev
>
>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 
>feature.

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 
>job, actually.

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

Please elaborate.

Kind regards,

  - Jonas

- -- 
* 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)

iEYEAREDAAYFAkoRsxgACgkQn7DbMsAkQLiieACgjnOow735pgDEJ4X8KAfyH+bS
jKQAnRJuygKBJDgU3S2u9JwxbVxt4Ueq
=Ymfi
-----END PGP SIGNATURE-----