cdbs vs dh (was: uploaded first pkg: pd-motex)

Fri Aug 13 13:10:19 UTC 2010

On Fri, Aug 13, 2010 at 01:58:18PM +0200, Benjamin Drung wrote:
>Am Freitag, den 13.08.2010, 10:40 +0200 schrieb Jonas Smedegaard:
>> On Thu, Aug 12, 2010 at 11:43:51PM +0200, Benjamin Drung wrote:
>> >Am Donnerstag, den 12.08.2010, 23:38 +0200 schrieb Jonas Smedegaard:
>> >> [1] or agree to repackage using cdbs - I just won't you to get the 
>> >> impression that I lured you into this: most people in the 
>> >> multimedia team are fine with - yeah, even prefer - short-form dh, 
>> >> it is just me being obnoxious.
>> >
>> >I prefer dh over cdbs over long debhelper form. Are there any 
>> >technical reasons for not using dh?
>>
>> Good question. Thanks for asking!

...and your question was easy and quick to answer exactly because you 
only asked for a one-sided view, not a(n attempt at) full comparison, 
which I suspect this thread may now turn into...

>> CDBS is more backports-friendly (beyond backports.org too!).
>
>That's true. Using bleeding edge packaging tools make backporting
>harder.
>
>> CDBS provides routines to fetch and repackage upstream tarballs
>
>I don't use this feature, but it could be useful.
>
>> CDBS provides routines to track copyright and licensing info of sources.
>
>That's nice. Where do I can read more about it?

Hehe, that's actually one thing CDBS lacks: proper and up-to-date 
documentation!

...and I don't even blog about it (yet - that's one of the planned 
outcomes of the Ikiwiki work I do with my girlfriend: she slowly started 
blogging quite some time ago but I set a bar so high for myself 
regarding "needed" features that I still - after a couple of years 
working on it - don't feel "ready").

Here's a quick intro (from my head - hope it works):

  1) Include /usr/share/cdbs/1/rules/utils.mk

  2) touch debian/copyright_hints
     (else you will simply be suggested to do this at each build)

  3) build as usual

  4) copy the autogenerated debian/copyright_newhints to debian/copyright 
     and verify and clean it up manually

...or what I do, and find smarter, is at 3) to a) build with "maintainer 
mode" enabled[1], b) manually apply patches, and c) only build the 
minimal necessary for the licensing check. Like this:

   QUILT_PATCHES=debian/patches quilt push -a
   DEB_MAINTAINER_MODE=1 debian/rules pre-build

Also, I cleanup with maintainer mode enabled, which keeps the 
debian/copyright_newhints file but tidy other noise in source:

   DEB_MAINTAINER_MODE=1 fakeroot debian/rules clean
   QUILT_PATCHES=debian/patches quilt pop -a

>> CDBS is less invasive - e.g. can be used with manually run dh_* 
>> commands
>
>You can use override_dh_* to run a dh_* command manually.

I might be wrong, but it seems to me that with short-form dh you add 
debhelper to *every* build target, trusting it to then properly handle 
anything thrown at it.

Yes, you can then explicitly disable parts of it - for the parts that 
debhelper happens to support disabling.

What you do with CDBS is *not* enabling the parts you don't want CDBS to 
handle for you.  As the prime example, you can choose to not let CDBS 
handle your debhelper routines but add that by hand.  When I discourage 
using CDBS together with short-form dh it is because I fear debhelper 
being too intrusive and automagically taking over parts that it 
shouldn't.  I would be more than happy to be assured that this is not 
the case, and they indeed work nicely together as long as you simply do 
not include the CDBS debhelper.mk snippet.

>> CDBS is written in make (short-form dh somewhat reinvents make in 
>> Perl)
>
>Yes, but Makefile rules can get complicated. Do you want an example? I 
>like dh because it's simple.

Perl code can be complex too.  You just tend to not look at that code.

What obviously helps is documentation.  I never used documentation 
myself for CDBS, just looked at the snippets, and I agree they may look 
scary to someone not intimate in make (similar to autotools being 
disliked by many).

Kind regards,

  - Jonas

[1] DEB_MAINTAINER_MODE enables features ireelevant or even policy 
violating to do by default (e.g. on build daemons). It makes the 
copyright-check routien fail, not just warn, in case of new or changed 
copyright and licensing info - which is always the case when you've 
initially touch'ed the file.

-- 
  * 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/pkg-multimedia-maintainers/attachments/20100813/06132e4a/attachment.pgp>