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

[Russ Allbery <rra@debian.org>]

Moving this discussion into the bug, since I'm not going to have a chance
to work on wording any time soon and I want to remember what we talked
about at that point.

Manoj Srivastava <srivasta@debian.org> writes:

>         In all of the following discussion, no one has ever said
>  anything about *WHY*  policy states that clean must undo what build
>  does. Unless we are clear on the rationale for dictum, trying to
>  resolve the issue is like playing blind man's bluff.

>         There are several reasons for wanting a clean target:
>  a) one should be able to iteratively tweak the source code, and so
>     the build/clean cycle should be idempotent.
>  b) The build process must be reproducible -- and this is where I see
>     the aautotools recommendation failing.  If we are supposed to be a
>     part of the free software community, we expect suers to contribute
>     back to us. One of the major areas where such help is needed is
>     debugging -- so someone building in a non-buildd or a non-one-shot
>     build process , should have the same, reproducible results as the
>     developer does.

>     So, if I ship some code, and I am on IRC with a user, they do
>     ./debian/rules clean, install some changes I suggest, we should
>     get the same compiler results -- without such a common baseline,
>     collaboration is made harder.

I agree with those goals.

Part of (a) is basically, "running build, binary, clean, build, and binary
again should result in the same packages the second time as the first,
modulo compiler timestamp differences."  In other words, I think what (a)
captures is that clean should return the package state to a place where it
can be built again with the same results.

The other half of (a) is something like "running build, binary, clean,
then modifying a source file, and then running build and binary again
should result in packages reflecting the change made to the source file."
In other words, clean needs to clean things up sufficiently that
modifications are noticed and acted on in the next build.

I think it's an open question how much we care about what detritus is left
around in the source directory provided that both of the above
requirements are met.  And I think that open question is exactly what this
thread is about.  I would rather require the above two principles, in some
form, than the current Policy language that says clean must restore a
pristine build tree.  The latter is a nice property, but it can be tricky
to provide, many packages don't provide this currently, and it's not clear
to me how really important it is (whether, in other words, not doing so
really introduces bugs).

As for (b), this is a general target that we can't ever meet completely,
since some aspects of the build system are going to change between the
point at which the package enters the archive and the point at which
someone else tries to rebuild it unless it's an arch-independent package.
The compiler will change, binutils will change, there will be a new libc,
etc.  The only difference between autotools and the compiler and that
autotools have historically been less stable for complex packages.  That
being said, for the packages I maintain, I've not had much difficulty with
newer versions of autotools doing something different than older versions.

>         Building packages from source is good -- but in this case, it
>  does introduce another variable as far as auto-tools and helper package
>  versions.  We can say that we find this acceptable -- and that package
>  should build depend on autotools, and _always_ run autotools in the
>  build process.  This would tend to find bugs in those packages quickly,
>  too.

>         Building from sources improves the package quality in the long
>  run, but does impact reproducibility, since now the tool chain
>  components have increased in number.

>         This also stands for lex, yacc, and swig output files.

This is where I'm at.  For those packages where the upstream files are not
sufficient for some reason, I would prefer to always run the autotools so
that I notice when things break.  In practice, things generally don't
break.

>         However, I wonder about the value of artificially reducing the
>  size of the diffs. there are tools for examing the diffs, and for
>  separating out the diffs on autogenerated files from diffs on true
>  source files. 

Yeah, I think diff size is one of the weaker arguments, the more I think
about it.  A more compelling argument from my perspective is that packages
really should be built from source, not from an intermediate form prepared
by the Debian developer.

To some extent, that same argument extends to upstream as well.  I can see
always running autotools period, even if the upstream-provided generated
files are sufficient.  There is no difference in principle, really.  But
as a practical matter, when the upstream files are sufficient, I think it
makes sense to leave well enough alone.  I have no strong principle on
which to base that position; it's just an argument from practicality.

>> I can imagine an argument for removing all of the intermediate files
>> (Makefile.in, configure, etc) in the clean target and rerunning the
>> autotools stuff from the build target.  This would provide a relatively
>> small diff (provided upstream doesn't ship the intermediate files),
>> although I am not sure of the wisdom of this approach.

Upstream basically always ships the intermediate files.  The only
exception in my experience are snapshots.

Doing this doesn't address the issue raised at the beginning of this
thread.  This approach violates the current Policy requirement for the
clean target since, unless one restores all of those generated files from
the original tarball on debian/rules clean, the clean target doesn't
restore the tree to the state it was in before running build.  This is, in
practice, difficult to do unless you maintain a snapshot of the tree
before you run the autotools, since they frequently change *many* files.

>         In my experience, upstream ships ancient versions of
>  intermediate files that often no longer work on hardware that Debian
>  supports.  This has been my experience with fvwm, and before the
>  current release, make.

Yup.

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