a problem with tools
We have a problem with our tools in Debian, and it's this:
Above the core tools in
dpkg-dev, and the nearly core tools in
devscripts, and the many different -- but all slowly converging --
revision control systems, there is the potential for infinite cruft to
pollute the source package.
Note that one developer's cruft is another developer's use of an excellent tool. If you don't believe that, you haven't read a lot of crufy upstream build systems, because Debian isn't the only project with this problem.
The source of this cruft is a near-constant stream of new tools that are each developed in good faith by someone who needs that tool, and then adopted and used in packages of a generally small percentage of developers, who think that tool might be a good fit for their problems. The tool isn't yet suitable for everyone to use, and most of these tools never become suitable for everyone, because
- making the leap from a special-purpose, poorly-designed hack to a general-purpose tools is hard
- getting the project to standardise on a tool is hard
- a tool often doesn't become general purpose until enough people use it, no matter how well designed it is to start out with
So after a while, a better, or at least different, solution to some of the same problems will come along, and some generally small percentage of developers will choose to use it in their source packages. Meanwhile, the developers who chose the old thing will be set in their ways and not want to use the new thing, and generally cannot be budged to stop using the old thing by any amount of argument.
Which in a sense is normal, and fine, until you have to collaborate with them. I don't care if someone I'm collaborating with uses emacs to my vim, but I do care if they use cdbs to my debhelper. I care because their tool-choice encrufts the source that I'm supposed to be working on.
Once a significant percentage of all the source packages in Debian are encrufted for a wide array of different tools, it will become harder and harder to work with Debian's source packages. We're already seeing this happen. Another way of looking at it is that we've invented dozens of source package formats that all work differently, aside from a small shared core, and we expect our developers to be able to use all of them.
At this point I see this as a huge, potentially killer problem, that is
making Debian development become worse with every passing year. But I
have no real solution. Obviously pointing out that tools are obsoleted or
bad doesn't work; we still have dozens of packages using
everyone agrees is horrible. That doesn't bode well, does it?
One partial solution is to design a category killer, and get it embedded in
acknowledged core tools. That's what I have tried, and so far, failed,
to do with an evolutionary change to the Debian source package format,
which I'd hope would give people a reason to stop using
and their ilk. As noted, this approach is Hard.
For now, I have no interest in being on a team that requires I use any of the following things:
- Any similar system that is used to move all patches to under the debian/ directory.
- Any system that puts the actual original upstream
- Any similar system that obfuscates debian/rules.
- Any special script that is required to be used to build a package as a
This means that I can't be on the security or release teams, and even teams like the perl team are getting sticky to be on.
PS, this doesn't mean I dislike quilt. I dislike quilt encrufting Debian source packages, which is entirely different.
PPS, In case you're wondering why debhelper gets a pass, it's because it's gone through the three numbered steps above to become a standard, general purpose tool, and has no serious competators. (Though it does have parasites, like cdbs.)