[Build-common-hackers] Teaching people about CDBS
dr at jones.dk
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
> 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, 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:
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
Hope that helps,
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
Size: 836 bytes
Desc: Digital signature
More information about the Build-common-hackers