Bug#397939: Proposal: Packages must have a working clean target

[Russ Allbery <rra@debian.org>]

Bill Allombert <allomber@math.u-bordeaux.fr> writes:
> On Fri, Nov 10, 2006 at 10:48:15AM -0800, Russ Allbery wrote:

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

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

> I already proposed we change policy to require that doing
> debian/rules clean
> debian/rules binary
> debian/rules clean
> restore the tree to the state after the first "debian/rules clean"
> providing no packages were installed or upgraded in between.
> This way, it is allowable for debian/rules clean to remove or change
> files shipped in the tarball providing this is idempotent.

I find running the autotools in debian/rules clean extremely
counterintuitive.  It also breaks how I handle my packages within a
revision control system, and given that I use svn-buildpackage in a fairly
standard mode, I expect I am *very* far from the only one.

What this basically requires is putting the generated output of the
autotools files in the diff.  This is only one of the options documented
in autotools-dev, and I think both of the options listed there should be
acceptable.  In practice, neither cause issues.

> I also proposed a different way to deal with config.guess/config.sub
> that comply with the current policy.

Yes, which is a neat approach, but I think it's still an open question
whether such workarounds should be necessary.  While that solution
provides a nice way to satisfy the current policy requirement, I see no
compelling reason *for* the current policy requirement, and therefore
don't see why one shouldn't be permitted to simply replace those files at
build-time with files provided by a build dependency.

If someone wants to use your technique, I certainly wouldn't argue with
them, but from a Policy standpoint I don't see how it causes less bugs or
creates a better distribution or packaging system than doing what many of
us have historically done.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>