Probably a clear winner. debhelper seems to have reached wide adoption because:

?JossMouette: a striking success example was dh_gconf. All packages using GConf have been fixed to follow the FHS for etch, thanks to the introduction of a single script.

NathanaelNerode: The modularization is a big reason why debhelper wins. Alternate tools are mostly too "one-size-fits-all"; debhelper has pieces for whatever you need, but you don't need to use them if they aren't relevant.

Brendan O'Dea:

It looks like developers agreed since today my Sources for main has 32 packages with a build-dep on debmake and 9827 with one for debhelper.

zegrep 'deb(make|std)' /usr/share/doc/*/changelog* | fgrep debhelper


Depends on whom you ask, cdbs is considered a failure by many and a blessing by others.

MichaelBanck: cdbs was successful, just ask gnome-debian. Sure, it wasn't always without problems...

?JossMouette: cdbs is a great tool when you have tons of similar packages. It was never meant for complicated packages and this is not how it should be used. But when you have dozens of GNOME packages or similar Python modules, with an active upstream following the same rules in all packages, it's a blessing. The GNOME team would never be able to maintain more than a hundred packages without such a tool.

?AaronUcko: one can use cdbs even for complicated packages, really, and some of us do, because we prefer to distill debian/rules down to that which is truly package-specific. That said, getting cdbs to DTRT in elaborate cases can be tricky, and I concede that traditional setups can be easier to follow.

Marga: well, all the others are positive, so I'm adding one negative. CDBS hides what it's doing. By having a 2-line debian/rules file, you don't know what's really going on. Also, the documentation sucks. When you need to do something different, you usually need to spend a lot of time trying to understand what's going on.

?FrankK├╝ster: Here is one more negative comment. The drawbacks Marga mentioned might be annoying when it is your own package. But they can get much more severe when you have to work on a package that someone else packaged with cdbs. For example for preparing an NMU to fix a RC bug, or for writing a patch to achieve something new. If - as someone who doesn't use cdbs himself - you cannot see why something goes wrong, or exactly as it happens, it is very hard to correct it. It's been more than once that I did not create a patch because the package used cdbs.



MichaelBanck: Huge improvement in QA when DDs started to build binary .debs from clean chroots. Standard practise today.

NathanaelNerode: What he said. Plus, since I run "testing" rather than "unstable" as my main system, pbuilder makes building in a up-to-date sid chroot easy, where it was tedious and complicated before.

Marga: even if Md says that building in a clean chroot hides bugs, I feel that any maintainer who's uploading packages that were not built in a clean chroot (be it with pbuilder, sbuild or any other similar tool) is wasting his/her fellow developers' time (FTBFS bugs are usually easy to fix, but they take time that could be use to fix real bugs).




MichaelBanck: The packaged version is only used by a small minority of DDs, it did not have the huge impact as pbuilder had. Of course, the original sbuild introducing autobuilding was a huge step forward for Debian ports at the time (but is not the topic).

?FrankK├╝ster, in reply to Roger Leigh:

> This applies to the DSA version, which is used on the 
> buildds. The sbuild package in debian however adds more 
> features, like schroot support. With this, it can use 
> schroot to create temporary, clean chroots from tarballs, 
> block devices, create lvm snapshots on the fly and so on. 
> I read Roger, that even xen support is planned.

Ah, great.  Good to know - this will probably require some 
reading and configuring, but it sounds it's worth it.


?GeorgeDanchev: success: lots of unofficial autobuilders are run, which saves official autobuilders not wasting time with doomed builds