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

[Jérôme Marant]

Let's move the discussion to pkg-emacs-devel@lists.alioth.debian.org.

Rob Browning <rlb@defaultvalue.org> writes:

> Jérôme Marant <jmarant@free.fr> 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.

I agree.

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

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

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

Honestly, you can't imagine adding libtool.

Currently, we have both autoconf and aclocal which are unlikely to
radically change.

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

Are you talking about a solution for Emacs or all your packages?
I'm quite sure there'll be no libtool nor automake in Emacs.

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

Even if next autoconf version brings changes, there is no doubt that
everything would happen at the toplevel only, not in subdirectories.

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.

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

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.

-- 
Jérôme Marant