Re: automake fun
On Thu, Nov 22, 2001 at 08:42:20AM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 22 Nov 2001, Denis Barbier wrote:
> > If maintainers do not run auto{conf,make} when packaging, then the problem
> > we are discussing here does simply not happen. We are trying to figure the
>
> If maintainers modify the .am or configure.in source files, they have to
> run auto* to propagate the changes to the other scripts. And it is the right
> thing to do, too -- but then, they must take care of the problem of
> filestamp skews.
>
> Note that this is different from running the autotools in the rules file.
>
> The proper fix is actually to get dpkg-source to touch all files that are
> patched to the same timestamp. This is the proper thing to do when you have
> a random-order timestamp skew-generating procedure, such as applying the
> debian diff over the unpacked tarball.
On Thu, Nov 22, 2001 at 12:48:52AM +0100, Denis Barbier wrote:
> On Wed, Nov 21, 2001 at 04:22:34PM -0500, Colin Walters wrote:
> [...]
> > Any other opinions? To summarize, we have five choices now:
> >
> > 1) Build-Depend on autoconf and automake: this doesn't really solve
> > the problem. Rerunning autoconf and automake is upstream's job.
> > 2) Change all the timestamps such that those rules will never be
> > executed.
> > 3) Comment out those rules in all the Makefile.in files as part of
> > your Debian diff.
> > 4) Make upstream use AM_MAINTAINER_MODE (Matt Zimmerman)
> > 5) Frobbing $PATH so that auto{conf,make} turn into /bin/true (Adam
> > Heath)
>
> 4b) Patch aclocal (+1 line) and automake (+2 lines) to force
> AM_MAINTAINER_MODE.
[For Colin: please note that I have written (4b) and not (6), because (4) and
(4b) are basically equivalent. It has been stated elsewhere in this
thread that (4) does only make sense if debian/rules if modified
to call configure with --disable-maintainer-mode, sorry for not
having written it explicitly]
All cases above except (1) do address the exact same issue, which is to prevent
auto{conf,make} from being run when building binary packages.
Case (2) fixes timestamp, whereas (3)-(5) do prevent those broken timestamps
from regenerating config files when building. But the result is the same.
Denis
Reply to: