How thorough must the clean target be?

A recent bug report prompted this question, which had been growing in the
back of my mind for some time.

Some packages run Autconf or Automake at build time, either because they
patch the build machinery or because the package is a CVS snapshot that
doesn't contain any derived files. My gnubg package is an example of
this. Currently, there are two methods for dealing with this, both of
which are blessed by the autotools-dev documentation: run Autoconf and
Automake beforehand and let the Debian *.diff.gz be huge, or run Autoconf
and Automake at build time. Both approaches have strong advocates, and I
think it's fair to say that previous debian-devel conversation has not
reached a project-wide consensus that one approach is better than the
other.

However, the current debian-policy statement about clean is:

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.

Taken exactly literally, this says that packages that run Autoconf or
Automake at build time must be able to reverse all changes that those
tools make when the clean target is run. Similarly, packages that copy
new config.sub or config.guess files at build time must save the old
versions and restore them when the clean target is run.

In practice, I think that would rule out running Autoconf and Automake at
build time except for simple packages, as those programs make fairly
widespread changes.

I'm not sure that's really what's intended, though. But maybe it is.
Thoughts on this?

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


--
To UNSUBSCRIBE, email to debian-policy-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

On Thu, Oct 05, 2006 at 10:44:53AM -0700, Russ Allbery wrote:
> However, the current debian-policy statement about clean is:
>
> 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.
>
> Taken exactly literally, this says that packages that run Autoconf or
> Automake at build time must be able to reverse all changes that those
> tools make when the clean target is run. Similarly, packages that copy
> new config.sub or config.guess files at build time must save the old
> versions and restore them when the clean target is run.

\usepackage[shameless]{plug}
\begin{plug}
I have proposed a (IMVHO) better solution to the
config.sub/config.guess problem see
<http://lists.debian.org/debian-science/2006/03/msg00038.html>
\end{plug}

> In practice, I think that would rule out running Autoconf and Automake at
> build time except for simple packages, as those programs make fairly
> widespread changes.

Well you can do 'make maintainer-clean' in the clean target. This will
remove any files generated by Autoconf/Automake. Did I missed something ?

The only unclear issues is files that exist in the tarball but get
removed in the clean target. However since dpkg-buildpackage default
to run debian/rules clean prior to build the package, one might consider
to limit the policy requirement to that case:

1> dpkg-source -x foo.dsc && cd foo-*
2> debian/rules clean
3> debian/rules binary
4> debian/rules clean

We would then require that the tree after 4 must be indentical to the
tree after 2.

Cheers,
--
Bill. <ballombe DeleteThis @debian.org>

Imagine a large red swirl here.


--
To UNSUBSCRIBE, email to debian-policy-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org