This one time, at band camp, Russ Allbery said: > Stephen Gran <[EMAIL PROTECTED]> writes: > > > clean > > > This must undo any effects that the build and binary targets may > > have had, except that it should leave alone any output files created > > in the parent directory by a run of a binary target. > > > We already have this rule, and it is a must directive already. > > As previously discussed, it's very difficult to comply with this directive > as written if one is following the autotools-dev recommendations for how > to regenerate the various autotools files. Before putting too much weight > on this directive, I'd really like to find some way of reconciling that, > since right now it's a frequently-violated dictate of Policy.
That's probably a bug in the autotools-dev recommendation, rather than a
problem with policy, though. For handling config.{sub,guess}, the
freeradius package has a reasonable method for cleaning up after itself.
For rerunning autotools at build time, well, I tend to think that's a
mistake, but we've had that fight before and I'm not really interested
in reopening it.
> Certainly, though, being unable to build a package twice is a bug that
> should be reported against that package. (I actually don't know if any of
> my packages have this problem; some of them have so many build
> dependencies that I always build them in pbuilder chroot. Hm.)
:)
But really, I tend to agree. If a package is unbuildable twice in a
row, it needs to clean up after itself better, and that is already a
bug, with the current policy.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : [EMAIL PROTECTED] |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
signature.asc
Description: Digital signature
