Comment 24 for bug 13458

Message-ID: <email address hidden>
Date: Wed, 09 Mar 2005 10:14:40 -0600
From: Rob Browning <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#297796: emacs21: FTBFS: timestamp skew issues.

J=E9r=F4me Marant <email address hidden> writes:

> What I don't understand is why you think that modifying configure.in
> and regenerating configure cannot be considered as part of a
> regular dpatch. Or maybe am I missing something?
>
> As an example, the amd64 port needs configure.in to be changed. I
> can the see the following scenario:
> - run dpatch-edit-patch
> - apply changes
> - run autoconf: this changes "configure"
> - exit from dpatch-edit-patch
>
> Why wouldn't this work?
>
> Why is it better to gather all changes to the configure script in
> a single separate dpatch rather than spreading all changes along
> with the patch it belongs to?

Because IMO modifications to configure.in (and any other autotools
related files, like Makefile.in for automake enabled packages, for
example) should be made in the .dpatch relevant to the overall change
in question. For example, the mailspool patch required changes to a
number of files in the source tree *and* to configure.in. I think
these configure.in changes should go in mailspool.dpatch, since that's
why they're there.

The changes in autofiles.diff are only supposed to be the result of
"whatever the autools change when run on a fully patched tree", and of
course that's not something you can predict without knowing all the
modifications that all of the .dpatch files have made to configure.in,
to any Makefile.ins (when automake is involved), and to any other
files that the currently installed version of the autotools might pay
attention to.

You could even imagine a foo.dpatch that adds libtool support to a
tree that didn't have it. This is going to cause a bunch of new
files/dirs to appear in the autofiles.diff, and exactly what appears
is going to depend on the version of libtool involved, the libtool
macros used in foo.dpatch, etc.

Also, as I mentioned before, part of the issue here is that I'd really
like to have a solution that's general enough to use with other dpatch
using packages, even ones that also use automake, libtool, etc.

> I almost all cases, changes to 'configure.in' only change 'configure'.
> In the remaining cases, changes only happen in the toplevel of the
> tree.

As suggested above, I don't think it's safe to presume that changes to
configure.in only change configure. Even if that's true now, it might
not be true for future versions of autoconf, and it's certainly not
true for packages where automake is involved. Actually, it might not
even be true in the current emacs21 package since we use aclocal, and
I suppose it's possible that aclocal might change what it writes to
aclocal.m4 (if anything) from version to version.

> I don't think it is unreasonnable to avoid duplicating the whole
> tree, isn't it?

That's what we do all the time when running dpatch-edit-patch, so I'm
not sure why it would be a problem when we're trying to capture an
autofiles.dpatch.

--=20
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 =3D 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 7=
3A4