Re: Best practice for cleaning autotools-generated files?

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Peter Samuelson writes ("Re: Best practice for cleaning autotools-generated files?"):
> Better to take on this risk, such as it is, by building from source
> every time.  It's the only way to know we _can_.  And fix whatever
> issues come up.  Even though it's not actually spelled out in the DFSG,
> I see it as a maintainer responsibility to ensure that our software
> builds from source on a Debian platform, even if you patch it, assuming
> your patch itself isn't buggy.

This is true and it would be fine to insist that our own builds of our
own packages on the intended distro always rebuilt the autotools
output.

But that doesn't mean that we should hobble the users who _aren't_
doing that, by deleting the files they need to achieve their
objectives without undue hassle.

> I see it as a question of, as the FSF puts it, "the freedom to study
> how the program works, and change it to make it do what you wish
> (freedom 1)."  A lot of us believe that's one of the main points of
> Free Software in the first place.  Access to source code isn't _just_
> to let you build on armel if the vendor only cares about i386.
> 
> If there _is_ some risk or perception of risk, that re-auto-tooling a
> package might break it, then we're not really providing the FSF's
> freedom 1.  [...]

That rerunning the autotools is sometimes difficult and sometimes
breaks things (because the attempt deletes the working output files)
is not a "perception", it is a fact.

Deleting the working autotools output files does nothing to help this
situation.  It just puts the user who only wanted to edit a .c file in
the same bad position as one who wants to add a new .c file or a new
autoconf test.

Ian.