[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Best practice for cleaning autotools-generated files?

On Sat, 7 May 2011 13:48:00 +0200
Enrico Weigelt <weigelt@metux.de> wrote:

> * Neil Williams <codehelp@debian.org> schrieb:
> > Not every generated file needs to be cleaned. The list can vary if the
> > package is very old and depends on how the package itself handles the
> > clean internally.
> IMHO, *all* generated files should be cleaned away, just to be sure.
> In the last decade I've encountered a lot of nasty problems w/
> forgotten generated files and similar stuff.

No. Reverting the build to the point where it is equivalent to only
what is in the VCS adds completely unnecessary build dependencies and
build stages. VCS is not the final source, it's a tool for upstream to
create the final source. I wouldn't want to work with any upstream
which does not produce stable tarballs which are available for download
without going anywhere near the VCS. I shouldn't even need to know what
VCS is being used if all I want to do is build the package for my own

I don't care what people say here, I am not putting the pre-tarball
build stages into the upstream build system of my upstream packages. I
usually document them in the README.svn but if it doesn't work, meh,
use the tarball which I ensure does work.

Overall, this has little to do with Debian. There is no consensus
amongst upstream teams, no benefit in breaking stable projects by
forcing a change in the build system and it just ends up as a simple
preference by whoever has commit access to the upstream. If those
people are happy with their own system, then arguing about tags versus
tarballs is just bikeshedding. 

Personal preferences have no place in a "best practice" statement -
that way lies the hell of mandating which VCS gets used, pandering to
whichever fanboy shouts the loudest.

> A good rule, IMHO, is: take *only* the *actual* source files (those
> written by the developers) and always regenerate all intermediate
> steps. Of course this means, _never ever_ use prebuild configure
> scripts etc.

Fundamentally disagree. That is a very, very, bad rule
IMHO. ./autogen.sh is a valuable aid and it is pointless to try and
assert that it should called in all builds. It can become necessary if
the latest upstream tarball has gone stale but that's about it. 

> To go even one step further: dont use tarballs, instead upstream's
> VCS release tags (assuming upstream provides that ;-o)

... and that is simply rubbish. Just because some teams want to use VCS
tags does not mean that all upstreams would consider such a change. As
an upstream developer, I simply refuse. The VCS is for upstream,
including the tags. What gets into distributions is the tarball because
then I can be sure that the package builds with 'make distcheck' without
using a new £$ %$£ branch for every "£$£" change between releases.
Lunacy. It's elevating a tool into a stick to hit people with. I've
only got one answer to that and it's NO.

One method does not fit all. I've got no problem with teams who do want
to use VCS tags as a release process but don't push your model on
others. All you'll get from my upstream projects is tarballs and if
the VCS tag doesn't build, I really don't care.

There is no such thing as a "release tag" in my upstreams, there might
be tags but those are often just experiments.

> > Building direct from VCS is a nice idea but sometimes, it just isn't
> > worth the pain - let the build system build the tarball and package
> > from the tarball. It's just easier. Or just change the build system
> > and/or the tool.
> Actually, when building directly from VCS release tag causes big pain,
> upstream is doing something _seriously_ wrong. So: fix the upstream
> or put in an intermediate project for the (distro-independent) QM
> works. (-> OSS-QM project).

NO. I am one of those upstreams and I do not care if any VCS tag causes
pain to anyone when building. The tarball is the released code, use it
or find someone else to package it.

Indeed, in a few upstream projects, the only files which ever get
tagged are the debian/ files. ;-)


Neil Williams

Attachment: pgpsTkygs32pp.pgp
Description: PGP signature

Reply to: