As distributors we should not discourage upstreams that wish to generate binary packages themselves, rather we should cooperate with them, and ideally they will end up maintaining their stable release packages in our distributions.
I agree. Robert goes on to talk about the tendancy Debian (and apparently
also Ubuntu) have to dislike upstream providing a debian directory.
Funny thing is that we also like to say team maintenance is a good idea. An
upstream who is doing packaging work is a readymade half of a team; if you
write them telling them to rm -rf debian, you are turning away a team
member. With a slap in the face. Worse, it's a team member who has
demonstrated that they are capable of working in far more complex systems
than a debian directory, since they wrote/maintain the software itself.
BTW, for those who are skeptical of teams, on the basis that they dilute responsibility: A team consisting of an upstream developer and a distribution maintainer is inherently the more healthy sort of team, where each member has a well-defined area of expertise, but can also venture outside their area when needed.
When I packaged FBReader for Debian, upstream already had their own packaging, and I worked with them to fix problems with it and make it something I could be happy maintaining. This was sometimes tricky, since upstream was also maintaining packages for maemo. Sometimes the tools were not ideal. It was still worth it.
On the other side of the coin, d-i is an upstream for several
distributions. If they told us we needed to rm -rf debian, we'd not have
a lot of d-i left.
tools
I also agree with Robert that most of the trouble comes down to problems with tools. BTW, RPM does not have these problems, and in that world it's typical for upstream to provide a spec file.
Much of the problem comes down to the crummyness of dpkg's source format,
which cannot rename files, delete files, etc. That the source format
directs us to 1970's source management (ie, tarballs and patches), instead of
21st century source management (ie, DVCS), doesn't help either.
dpkg's 3.0 quilt source format tries to address the issue by removing any
debian directory in upstream's tarball. I am not sure that this is at all
the right approach; it makes it harder, not easier to work with upstream as
a team.
A better approach might be to consider anything that hardcodes the debian
directory as having a bug. If upstream can easily package debs using a deb,
or maemo, or ubuntu directory, you sidestep any potential conflict while
still being able to work with them via a symlink.
To put my time where my mouth is: Anytime debhelper prevents working
with an upstream who wants to ship a debian directory; that is a bug. I
will fix them. (Note that debhelper already provides a --ignore that can
be used if upstream has provided a dehelper control file that you can't
delete and don't want used.)
Previously: Look who's packaging