[Build-common-hackers] Teaching people about CDBS

Fri Apr 15 22:23:36 UTC 2011

Hi [again] Phil,

On 11-04-15 at 10:34pm, Philip Hands wrote:
> [This is a repost of a mail that was originally sent privately to 
>  Jonas, which he asked me to post here to then provide him the chance 
>  to give his helpful reply a wider airing -- I hope you all find it 
>  useful]
> 
> Hi Jonas,
> 
> I hope you're well.

Thanks, I am.  And reading this letter helps too :-D

It just occurs to me that my image of you is "...with a smile".  I 
actually never recall having seen you not happy.  So I just assume you 
ae well too ;-)

> I'm giving a tutorial on Debian package building in May[1], and while 
> it might be tempting to allow my bigotry to win, and just say "Don't 
> use CDBS" I don't think that is really the right thing to do, 
> especially since I'm sure that some of the attendees will be wanting 
> to know about packaging because they want to be able to apply local 
> patches, which means they're very likely to need to patch CDBS based 
> packages at some point.
> 
> Also, from your recent comments about CDBS, it seems that I ought to 
> have another look at it, since it sounds like it's changed quite a lot 
> since I developed my bigotry ;-)

Thanks a lot for the kind words.  Quite encouraging!

> So, that being the case, I was wondering if you could point me at good 
> example packages that demonstrate CDBS's strengths, or illustrate why 
> one might want to prefer CDBS over dh7.  Also, if there's and good 
> intro that you could suggest, that would be great too.

to take that last thing first: Documentation is shitty. Flat out.  We 
are working on improving that, but nothing concrete yet.

I generally try to tidy all packages that I am involved in packaging, so 
ideally you should be able to pick from any of the 200+ packages here: 
http://qa.debian.org/developer.php?login=Smedegaard&comaint=yes

In reality, however, there is obviously ones more polished than others.

Just today I noticed the following changelog entry in pango1.0:

   * Switch to CDBS with its awesome flavors support.

...so perhaps grab that package as example.  Flavored builds are one of 
the recent features of CDBS, here needed to compile udebs specially 
AFAIK.  The pango1.0 package also nicely (more so than my common 
packaging style) uses make variables and expansions, which IMO is the 
core argument for CDBS over short-form dh: The ddebian/rules file is a 
make file and CDBS extends on that instead of reinventing make (e.g. 
graphing algorithms for dependency chaining of build tasks) in Perl.

Another example package to look at is ghostscript, relying on several 
features that I cannot imagine how to do without CDBS:

Dependencies of binary packages declared in debian/rules.  Ghostscript 
have had a messy past, which has caused a lot of transitional quirks.  
When I started cleaning up, some of those quirks was wrong (leading to 
circular dependencies) and others were outdated.  Declaring in 
debian/rules makes it easier to document each quirk, and to make the 
actual package names/versions in a quirk be resolved from e.g. ABI or 
some cross-quirk logic - good example of this last one is the Sugar 
packages that largely reuse the whole debian/ subdir across multiple 
_source_ flavors of the packages (see e.g. sugar-base-0.90, and pull its 
git to see how sugar-base-0.84 and other flavors are maintained in same 
framework - and even tracking upstream git as well).

Automated binary package renaming (and more) at major version bumps. Try 
grep for __VER__ to see the places that would have needed manual 
tweaking at each major version bump (easily risking to forget one of 
them).  With CDBS this is resolved automagically when in "maintainer 
mode" (due to such changes being illegal to do during normal builds):
     DEB_MAINTAINER_MODE=1 fakeroot debian/rules clean

Automated build-dependency resolving.  When in maintainer mode, also 
build-dependencies tied to CDBS snippets are automagically resolved.  
There is no guarantees - it is still the responsibility of the 
maintainer to check the sanity of it, but should be a help e.g. to know 
what changelog entries of the corresponding package to investigate 
closely to check if really that versioned tightening is relevant for 
this package or not.

Tracking copyrights and licenses.  Ghostscript is a pretty large 
package, with lots of authors and many different licenses.  Keeping 
track of it all is difficult.  When enabled (as in ghostscript) then 
during normal builds it warns if there are new/changed licenses or 
copyright holders and when in maintainer mode it fails to build in such 
situations.  As a bonus, the format of the file used for tracking is 
DEP5 so can be used as initial draft for writing the copyright file 
itself as well.

Getting upstream source.  There are multiple trends in this area, the 
uscan tool and a get-orig-source make target being the most common.  
CDBS offers a get-orig-source mechanism with support for verifying 
md5sum, DFSG repackaging and recompression (see uw-imap for that last 
one in action).

Some of above packages are pretty complex.  Simple packages also benefit 
from CDBS, but apart from the upstream-tarball and copyright-check 
snippets (which ideally should be offered as independent tools instead 
of tied to CDBS) the difference there compared to short-form dh is 
probably "just" its style: I suspect few package maintainers understand 
the make language and therefore dislike it. I like make so is sceptical 
to short-form dh "reimplementation" as backbone for the build process.

Regarding documentation: What I do myself is consult "info make" (not 
"man make"!) and read the actual CDBS snippets below /usr/share/cdbs 
when I want to figure out which variables or build targets to use for 
what purpose.

Hope that helps,

  - Jonas

P.S.  Thanks for reposting.  I sure hope others here on the list will 
add their additional notes, and correct flaws in mine.

P.P.S.  You mentioned you'd correct some typos when reposting and that 
made me curious as I didn't recall spotting more than one.  And to my 
surprise that one is still there in this repost: In last paragraph of 
yours "and" apparently should've been "any" :-P

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20110416/71bbc572/attachment.pgp>