Comment 17 for bug 13458

Revision history for this message
In , Rob Browning (rlb) wrote : Re: Bug#297796: emacs21: FTBFS: timestamp skew issues.

Jérôme Marant <email address hidden> writes:

> I don't agree. It only has to be documented. Let's be frank: I
> personaly don't like the idea of the voodoo magic which acts in the
> shadow and breaks unexpectedly some random day.

By "voodoo magic" do you mean the old approach, the possible md5
approach, or 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.

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

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.

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

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

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