Joey has a problem with tools used over dpkg-dev’s core tools to help maintainers maintain their debian packages.
I was wondering about the adoption of those tools, so I simply grepped the logs from my last rebuild for “^Setting up $TOOL “, which is more accurate than looking at build-deps, since someteam-pkg-tools could depend on cdbs, and hide cdbs usage.
Results, with lists of packages “affected”:
| Tool | Packages |
|---|---|
| debhelper | 11434 (95.8%) |
| cdbs | 2665 (22.3%) |
| dpatch | 1714 (14.4%) |
| quilt | 935 (7.8%) |
| dbs | 57 (0.47%) |
| yada | 32 (0.27%) |
| debmake | 2 (0.017%) |
(if you want me to check the logs for another tool, just tell me)
My personal opinion on this is that tools that make sense are slowly getting adopted (that probably includes debhelper, cdbs, dpatch and quilt). The main difference between debhelper and the other tools is that the other tools don’t try to solve a problem for everybody. cdbs perfectly makes sense for some packages: the simple ones, where you only have to modify 4-5 lines in the output from dh_make to build properly.
Patch systems are also a good way to track changes made to upstream source, and probably encourage giving back patches to upstream. Note that my stats don’t include packages using cdbs’ simple-patchsys, so there are probably really close to 1/4 or 1/3 of our packages using some sort of patch system. How course, having simple-patchsys, dpatch and quilt sounds a bit stupid. But last time I checked, nobody took the time to blog a comparison of those tools, saying why {quilt,dpatch} is better than {simple-patchsys,dpatch,quilt}. Also, simple-patchsys probably makes a good-enough job for its users, so they don’t see the point in changing.
Of course, it’s easier to bury your head in the sand, and ignore the fact that those tools solve real problems for so many people and packages, and make their lives easier. :-)
The results show which of the tools are used, but not which tools the developers are directly using.
cdbs depends on debhelper, so these results are actually saying that only 96%-22%= 74% of packages use debhelper and not cdbs in debian/rules.
I wonder how this correlates to the date the package was first created – is any particular tool becomming more popular over time?
mmh, we could graph the evolution of the use of tools using snapshot.debian.net. But that’s a lot of work.
Simple-patchsys is not so much a problem, because it is trivial to migrate from it to quilt. When it becomes insufficient for the job (understand: when you have more than 2 patches), you just need to create a file, change a line in debian/rules, and add a build-dep.
Why quilt is better than dpatch? I also googled around to find answers/discussion, without much luck. One reason is that dpatch copies the whole tree to calculate your diff, whereas quilt only compare the files that you’ve told it about. Makes a difference when working on big packages.
Quilt also has the concept of an ordered stack of patches, where you can e.g. easily fast forward through patches 1-4, adjust patch 5, then reapply patch 6-9 etc.
Hi Lukas,
Seeing the “2” behind debmake in your blog post, I made a short sprint this weekend and all of debmake is now gone :-)
Thijs
Hi Lucas, thats an interesting statistic. You said that looking at build-deps is not appropriate, but I disagree with that in some kind. I did a quick queck with build-rdeps (which is a new tool in the devscripts) and found only small differences between your numbers and those that can be determined with build-rdeps. Just as a possible interesting sidenote ;)