Above the core tools in dpkg-dev, and the nearly core tools in debhelper
and 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 yada, which
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 dpatch, dbs,
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:

dpatch

dbs

quilt

Any similar system that is used to move all patches to under the debian/
directory.

Any system that puts the actual original upstream .tar.gz inside
an .orig.tar.gz.

yada

cdbs

Any similar system that obfuscates debian/rules.

Any special script that is required to be used to build a package as a
wrapper around dpkg-buildpackage.

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.

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.)