Jérôme Marant <[EMAIL PROTECTED]> 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