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

[Jérôme Marant]

Rob Browning <rlb@defaultvalue.org> writes:

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

In case automake is used, yes.

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

By broken, I meant something changed in autotools which makes
things work differently for us and thus breaks.

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

Ah.

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

I depends how much it cost, but let's see.

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

Err, I swear that despite what's written in the doc, many people
told me that it was a bad practice.

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

Right.

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

Yes. Could you explain what do you in mind exactly and how you want to
do it exactly?

If you mean what you proposed

>   define update_autofiles_diff_if_needed
>     md5sum debian/*.dpatch > debian/tmp-dpatch.md5
>     if ! cmp debian/dpatch.md5 debian/tmp-dpatch.md5; \
>     then \
>       $(update_debian_autofiles_diff); \
>       md5sum debian/*.dpatch > debian/dpatch.md5; \
>     fi
>   endef

you seem to condition the regeneration of autodiffs by any dpatch
being modified, don't you?

Or maybe do you have any other solution in mind?

-- 
Jérôme Marant