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 ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How thorough must the clean target be?
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. [EMAIL PROTECTED]
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How thorough must the clean target be?
On Thu, Oct 05, 2006 at 08:28:06PM +0200, Bill Allombert [EMAIL PROTECTED]
wrote:
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}
Neat ! Please put that (well, rather the exec version) in the developer
reference !
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How thorough must the clean target be?
On Thu, 05 Oct 2006, Bill Allombert wrote:
\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}
You know, I'd have appreciated getting that email filed as a bug against
autotools-dev instead of finding about it in this thread.
It is a good idea, I will add it to autotools-dev.
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.
Seems *very* good. Asking for the tree after 4 being the same as the tree
before 2 is not useful to Debian packages at all, and it *is* a hassle that
requires often more expensive build strategies.
I'd second a proposal for the tree after 4 must be indentical to the tree
after 2.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How thorough must the clean target be?
Bill Allombert [EMAIL PROTECTED] writes: On Thu, Oct 05, 2006 at 10:44:53AM -0700, Russ Allbery wrote: 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. That's the part that seems to still contradict the current policy wording. Policy says that the clean target has to undo everything that build did. If build ran Automake, removing all Makefile.in files doesn't seem like undoing that. It seems just as far from undoing as leaving the newly generated ones in place. 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. Packages that run Autoconf/Automake during build would still fail this, unless they ran Autoconf/Automake during clean. And doing the latter is functionally equivalent, with most build tools, to running Autoconf/Automake at packaging time and including the results in the diff. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How thorough must the clean target be?
Mike Hommey [EMAIL PROTECTED] writes:
Bill Allombert [EMAIL PROTECTED] wrote:
\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}
Neat ! Please put that (well, rather the exec version) in the developer
reference !
It's kind of neat, but I'm not sure it's really any better than just
replacing config.{guess,sub} at build time and it's functionally
equivalent. Either way you have to build-depend on autotools-dev, so it's
a question of preference of one more patch versus two lines in
debian/rules.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How thorough must the clean target be?
Russ Allbery [EMAIL PROTECTED] writes: 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'd characterize this as mainly a problem with automake (and libtool, IIRC, though I generally try to stay clear of both), as aclocal, autoconf, and autoheader generally only change one file apiece. Anyway, one (admittedly somewhat heavyweight) solution for such cases is to copy *everything* to a new directory, modify it to your heart's content, and blow it away when done. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How thorough must the clean target be?
On Thu, Oct 05, 2006 at 03:50:47PM -0300, Henrique de Moraes Holschuh wrote:
On Thu, 05 Oct 2006, Bill Allombert wrote:
\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}
You know, I'd have appreciated getting that email filed as a bug against
autotools-dev instead of finding about it in this thread.
Sorry, it get buried in the thread you started there
http://lists.debian.org/debian-devel/2001/07/msg01595.html
my post being msg01777.html (apology to any reader not yet born in 2001/07).
It is a good idea, I will add it to autotools-dev.
Something which is less a good idea but it useful with packages
with eon-old libtool is that one:
Build-dep on libtool and do:
printf '#!/bin/sh\nexec libtool $$@\n' libtool
This way the package use /usr/bin/libtool which is up-to-date.
Cheers,
--
Bill. [EMAIL PROTECTED]
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How thorough must the clean target be?
On Thu, Oct 05, 2006 at 09:53:55PM +0200, Bill Allombert wrote: It is a good idea, I will add it to autotools-dev. Something which is less a good idea but it useful with packages with eon-old libtool is that one: Build-dep on libtool and do: printf '#!/bin/sh\nexec libtool $$@\n' libtool This way the package use /usr/bin/libtool which is up-to-date. Please don't do that. The /usr/bin/libtool is a patched version, so it could be used for things not having it's own libtool, but it's not really recommended. Please use the version as generated by configure instead. I've even considered not putting that file in the package at all, and might remove it in the future. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How thorough must the clean target be?
On Thu, Oct 05, 2006 at 12:28:11PM -0700, Russ Allbery [EMAIL PROTECTED]
wrote:
Mike Hommey [EMAIL PROTECTED] writes:
Bill Allombert [EMAIL PROTECTED] wrote:
\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}
Neat ! Please put that (well, rather the exec version) in the developer
reference !
It's kind of neat, but I'm not sure it's really any better than just
replacing config.{guess,sub} at build time and it's functionally
equivalent. Either way you have to build-depend on autotools-dev, so it's
a question of preference of one more patch versus two lines in
debian/rules.
Note that these two lines in debian/rules create a quite big patch...
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How thorough must the clean target be?
Mike Hommey [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] wrote:
It's kind of neat, but I'm not sure it's really any better than just
replacing config.{guess,sub} at build time and it's functionally
equivalent. Either way you have to build-depend on autotools-dev, so
it's a question of preference of one more patch versus two lines in
debian/rules.
Note that these two lines in debian/rules create a quite big patch...
The whole point of doing it in debian/rules is that it *doesn't* create a
big patch, at least the way that I do it (which is in the build target
before running configure).
I really don't like the practice of doing this in the clean target. That
behaves very badly for the way that I maintain Debian packages, since it
means I'd be regularly releasing something different from what's checked
into the VCS. Doing it optionally depending on the existence of a file
adds non-deterministic build behavior as a bonus.
I can understand the feeling of the people who like to just take care of
all the Autotools stuff and leave a big patch, but it's a *really* big
patch and I like to be able to read through the Debian patch using
filterdiff -x '*/debian/*' and make sure I understand everything that's
changed (or, for most of my packages, make sure that there's nothing left,
since I use quilt). I'd rather notice and fix build problems related to
newer versions of the Autotools.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
