Re: Thoughts about src-dep implementation
Joey Hess <joey@kitenet.net> writes:
> debian/rules clean is already required to reverse the effects of the build.
In theory, yes. But unless you audit the .diff.gz, it's not
necessarily obvious if this fails. Now, I *do* audit my diffs, so I
know *exactly* where I've come up short (one package, which I very
recently adopted, where I did a mostly unedited upload just to get my
name in the maintainer field). If I didn't audit my diffs, I think
I'd have at *least* four or five packages where the clean target
didn't do its job completely.
> Anyone who builds a package twice in the same directory knows this. As
> you've mentioned below, you don't. I expect most people do, though.
No, I suspect that most people simply don't notice, since the only
result is that the diff ends up a little larger than it would be
otherwise.
Of course, if your upstream maintainer is on top of things, and "make
distclean" works, then you probably don't have a problem. But a lot
of times, that's not the case, and I've had to add extra cleanup code
to several packages.
The fact is that at the moment, if clean does a less-than-thorough
job, then garbage ends up in the diffs, but everything works fine, and
nobody notices. However, if we start to depend on clean doing a
thorough job, I think we're going to have some unpleasant surprises.
Perhaps I'm overstating the pervasiveness of the problem, but it's
still a very real problem.
For an obvious example: *EVERY* gnome package I've looked at (balsa,
gnome-objc, gnome-libs, orbit) fails to clean up properly. How many
of you knew that? :-)
> My experience is counter to yours
Is it? Or are you just not looking that closely? I'm willing to
believe you only because I know you're a God of Packaging. I suspect
that most of us mere mortals are not quite so careful. :-)
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: