> There are also pretty significant differences in the design goals of > debhelper and cdbs, differences which I believe have a major impact on the > ability of maintainers to understand their own packages and on the > respective helper-induced build failure rates of the two. I think these are > very pertinent reasons not to recommend cdbs to novice maintainers. I tend to agree. I think it's important for new maintainers to understand how their packages are built. For this, the very classical approach of debian/rules with debhelper commands is a good compromise between readability and accessibility. On the other hand, the constant changes and new neat features introduced in Debian (new debhelper commands, new ways to handle stuff, etc) is a big challenge for maintainers to cope with (in short, I bet that mostly noone except the debhelper maintainer is really aware of all debhelper nice features....). Using cdbs is indeed a very convenient way to be sure that packages use a kind of common build method, which allows major build design changes without big communication to developers. Of course, this assumes that cdbs is kept up-to-date with recent evolutions of the Debian packages build process and new neat features in debhelper. I actually use cdbs for several of my packages, the most important being shadow (others are font packages which are usually very simple). In that specific case, I find it particularly convenient because it allows the debian/rules to only list actions that are very specific (actually, things that are done "by hand" for various reasons, good or bad). The funny goal of having one-liner debian/rules files, with cdbs, is indeed a very good way to track down all hacks, dirty or not, we are currently using in debian/rules files....which is, for the long term, a good improvement. But, be safe, Steve, I won't push for cdbs in samba (even though, ahem, it's debian/rules file has room for improvement probably)..
Attachment:
signature.asc
Description: Digital signature