Comment 23 for bug 13458

Message-ID: <email address hidden>
Date: Wed, 9 Mar 2005 16:43:11 +0100
From: =?iso-8859-1?b?Suly9G1l?= Marant <email address hidden>
To: Rob Browning <email address hidden>, <email address hidden>
Subject: Re: Bug#297796: emacs21: FTBFS: timestamp skew issues.

Quoting Rob Browning <email address hidden>:

> By "voodoo magic" do you mean the old approach, the possible md5
> approach, or both?

The combination of both.

> If you mean the old approach, then I obviously don't see it to be as
> cut and dry as you do. To be fair, the only reason the current code
> broke is because the relative timestamps for files in the debian diff
> are unpredictable, and I didn't think about that. Of course, that
> means that *any* files mentioned in the debian patch are potentially
> trouble as far as make is concerned. Without this problem, it would
> have been quite correct to have autofiles.diff depend on the files
> that may influence its contents (i.e. the *.dpatch files).
>
> Of course if you just mean that the .md5 approach would be "voodoo
> magic", then I'll agree that it's not completely straightforward.
> Though to the extent I've thought it through so far, I haven't come up
> with any problems.

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?

> In any case, even if we go with the "only update when requested"
> dpatch-edit-patch approach that I think you're advocating, I'd still
> want a target for it so we can just invoke that when needed,
> i.e. something (only very roughly) like this:
>
> update-autofiles-diff:
> # rm aclocal.m4 so it doesn't confuse newer autoconfs, but to=
uch it
> # so ./Makefile won't be upset if it's not recreated (b/c not
> needed).
> (dpatch-edit-patch ... autofiles.dpatch
> && cd DPATCHDIR \
> && rm -f aclocal.m4 \
> && touch aclocal.m4 \
> && aclocal \
> && autoconf
> && exit)
>
> (...which is really not that much different than what we're already
> doing, but I'll agree that handling everything with dpatch would be a
> bit cleaner, and if it works right, then I'm fine with that.)

It would be kind of better, yes.

> So it seems like the *only* thing we're in potential disagreement
> about is whether we should automatically invoke this target *iff*
> there's a solid way to automatically determine when doing so would be
> appropriate.

I think so.

> > IMO, creating a whole copy of the tree and diffing at build-time is
> > not worth the effort. You have the final word, anyway :P
>
> It's not only not worth the effort, but it should never have happened
> under normal circumstances. As I mentioned, the only reason it did in
> this case was because I didn't consider the problem presented by the
> timestamps of files in the debian diff and so came up with a broken
> solution.

I almost all cases, changes to 'configure.in' only change 'configure'.
In the remaining cases, changes only happen in the toplevel of the
tree. I don't think it is unreasonnable to avoid duplicating the
whole tree, isn't it?

> The way things were intended to work, the autofiles.diff should only
> have been re-built if you changed a relevant file (i.e. *.dpatch), or
> if you manually requested a rebuild during "prepare-release".

I understood that.

--
J=E9r=F4me Marant