This one time, at band camp, Russ Allbery said:
> Stephen Gran <sgran@debian.org> 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 |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature