I'm quite a fan of CDBS and I'm currently writing handlers for debian/rules to create cross-building packages for Emdebian [1]. I've found CDBS somewhat easier to automate - mainly because hand-crafted debian/rules files can be quite disorganised and hard to interpret/patch. The basic task is to omit certain dh_install* helpers to prevent the packaging of ChangeLog, debian/changelog, README, TODO and all the other non-program text that is normally part of a Debian package so that Emdebian can fit on a 20Mb device (like an iPAQ) whilst using Debian packages. Some debian/rules files don't use the debhelper routines, requiring hand-editing of debian/rules to 'emdebianise' the package by omitting certain direct calls to ${INSTALL} etc. My own packages [2] [3] are all CDBS and I have found no reasons not to use it. I prefer to sponsor CDBS for these reasons but I've no particular problem with not using it. Yet some sponsors have made it clear that CDBS is not their preferred method and are somewhat unwilling to sponsor CDBS. I don't use automatic debian/control management and I personally wouldn't recommend using that part of CDBS. What are the problems with CDBS (apart from debian/control automation)? Which kinds of packages have the most trouble with a CDBS method? (There are CDBS classes for Perl, Gnome, Autotools and a few others) [4]. [1] http://www.emdebian.org/ [2] http://qa.debian.org/developer.php?login=linux@codehelp.co.uk [3] http://qa.debian.org/developer.php?login=codehelp@debian.org [4] http://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpFAt2zKN5Av.pgp
Description: PGP signature