2971
Comment: Typo fix.
|
3278
|
Deletions are marked like this. | Additions are marked like this. |
Line 15: | Line 15: |
Brendan O'Dea: http://lists.debian.org/debian-devel/1997/09/msg00901.html 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 }}} |
debhelper
Probably a clear winner. debhelper seems to have reached wide adoption because:
- it was created early on, while everything was still in flux
- it made people's lives easier without being too obscure
- documented, consistent, elegant
?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:
http://lists.debian.org/debian-devel/1997/09/msg00901.html
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
cdbs
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.
yada
pbuilder
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.
debuild
cowbuilder
sbuild
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.
wanna-build
?GeorgeDanchev: success: lots of unofficial autobuilders are run, which saves official autobuilders not wasting time with doomed builds