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

[Peter Eisentraut]

On Monday 18 May 2009 22:12:25 Jonas Smedegaard wrote:
> >* Require debhelper 7 and rely on its defaults.
> 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.

I did not mean to propose anything like that.

Here is what I mean.  Currently, debhelper.mk does something like

DEB_INSTALL_CHANGELOGS_ALL = ... $(shell for f in ChangeLog Changelog Changes 
CHANGES changelog CHANGELOG; do if test -s $(DEB_SRCDIR)/$$f; then echo 
$(DEB_SRCDIR)/$$f; break; fi; done) ...

dh_installchangelogs -p$(cdbs_curpkg) $(DEB_DH_INSTALLCHANGELOGS_ARGS) 
$(DEB_INSTALL_CHANGELOGS_ALL) $(DEB_INSTALL_CHANGELOGS_$(cdbs_curpkg))

We could drop that first line and just tell people to use debhelper level 7, 
because it does the same thing already.

It will need some phasing in and out, of course.

But this does not force anyone to use debhelper or debhelper with cdbs, 
because you don't need to include debhelper.mk, after all.

> * Structured feature "aging"
>
> Let's cleanup features that are no longer relevant - but not cleanup too
> aggressively either.

Sure, I didn't mean to switch everything tomorrow. ;-)  I have none of this 
written anyway, btw.  Just shooting off crazy ideas.

> We should support features in stable Debian (e.g. DH6), to not break on
> partly upgraded systems.

lenny actually has DH7.

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

What debhelper does with the level is do a bunch of if level >= N do this.  
That's the same thing I have in mind.

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

That sounds more like a rewrite and double maintenance.  Which might be 
valuable, but I have no immediate interest in it, and it doesn't achieve my 
goal with this item of introducing small incompatible changes gradually, 
without breaking this, as we have in the past.

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

Yes, it should be optional, but it might be fun to try out.

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

OK, I will do an analysis of how widely used it is and if there are any 
showstoppers for people to move to quilt, and then come up with a transition 
plan.  It will likely be a very long plan.

> (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.)

Well, independent of everything else, clearly all intentional functionality 
should be documented, and new features should come with documentation.  If 
there are problems with that requirement (e.g., unfamiliar with the tools?), 
we can try to help.

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

Basically, I am quite unclear on why one would want to use it and how, and 
half of the use cases you mention above are unknown to me.  If you are 
interested, then by all means let's keep it and make it work properly and 
document it and expand it.  But right now it's pretty weird and obscure, I 
think.

Btw., "reimplementing" Cpu/System support will hopefully become unnecessary 
soon once dpkg architecture wildcards become usable.

Hmm, quick readup on xcontrol, maybe it would be better to pass off much of 
the logic to there and have cdbs only invoke xcontrol.  That would move cdbs 
back to the spirit of makefile snippets calling separate programs (as 
makefiles typically do), as opposed to boatloads of original shell script 
logic only callable in cdbs.  Sounds interesting.  Needs more thought.

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

Yeah, I like the collab-maint idea.  If you want to do a conversion, could you 
please explain first which of the many build-a-package-with-git theories you 
subscribe to.  Just so we're clear for the future. ;-)

> >* new version numbering scheme
> >
> >something like 1.2.3, like debhelper
>
> Please elaborate.

Basically, 1=major new things, 2=new features, 3=bug fixes.  Instead of 0.4.
(whatever..infinity).