Bug#297796: emacs21: FTBFS: timestamp skew issues.

[Rob Browning]

J=E9r=F4me Marant <jerome.marant@free.fr> writes:

> I agree.
>
> BTW, only configure.in is relevant here. Changes to Makefile.in are just
> like any other source file.

Sorry, I meant changes to Makefile.am, which may cause changes to the
shipped Makefile.in when automake is re-run.

>> 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.
>
> Sometimes it is good to realize that something breaks, usually
> upstream needs to be warn about this ...

Sure, but I wasn't talking about cases where anything was "broken",
just about normal, expected changes in things like Makefile.in,
configure, whatever libtool does, etc. as a result of patches that
affect their source files.

> Honestly, you can't imagine adding libtool.

Not to emacs, of course, but see below...

> Are you talking about a solution for Emacs or all your packages?

Yes, as I mentioned previously, I'd prefer to come up with an approach
that I could use on other packages too if it's not substantially more
difficult or complex.

>> 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.
>
> Even if next autoconf version brings changes, there is no doubt that
> everything would happen at the toplevel only, not in subdirectories.

I'm still not comfortable presuming that for projects we don't
control, especially when things like libtool (and gettext?) do create
subdirs under some conditions.  Anyway, if it's easy to avoid the
possibility of this being a problem, I don't see why we shouldn't.

> Anyway, I have a different point of view: I usually like to know what
> changed in autotools whenever something changed, this is why I prefer
> that a breakage happens and makes me realize that something
> changed. This is why, for instance I don't like the idea of
> automatically copying config.{guess,sub} from outer space.

You probably already know this, but that's the recommended practice
for pacakges AFAIK: /usr/share/doc/autotools-dev/README.Debian.gz

> This is it. We do it but _only_ when generating our patches, not
> when the package gets built. I was pointing out the rule in the
> makefile which is meant to regenerate all the stuff at built time.

I understand the concern about automagically trying to re-generate the
autofiles.diff, and in fact, it's an approach that I was unsure about
when I implemented it.  It should have worked fine, but didn't because
of the diff/timestamp issue.

In any case, after our discussion, and as I suggested a message or two
ago, I'd prefer to change things so that we don't automatically
regenerate the diff, and I'd like to see about using the md5 solution
I mentioned before to detect when the autodiff might be out of date.
If that turns out to be relatively easy, which I suspect it will, then
I'd like to use that to decide when to tell the user that they need to
re-generate the autodiff.

Would that satisfy your concerns?

--=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