On 02/08/2013 01:40 PM, Diego Elio Pettenò wrote: > On 08/02/2013 13:26, Stefano Lattarini wrote: >> But maintainer-mode won't help you here; it will just cause make to ignore >> some remake rules that require maintainer tools, so you are *more* likely >> to end up with a subtly and silently broken package (or at least one that >> is in an inconsistent state). No? > > Definitely not inconsistent: it'll be consistently messed up in the same > way. > >> (Aside: No it doesn't; if a package has been bootstrapped with 1.9.x, >> it will call "automake-1.9" and "aclocal-1.9" in the rebuild rules, >> ensuring the correct versions are used, or that the remake fails if >> those versions are not available). > > Sometimes, sometimes not. I've seen it happen, especially for older > automakes. > Ah, if you go back to automake 1.4, then you're right; the versioned binaries where introduced in the 1.4 -> 1.6 transition exactly to prevent this kind of problem from then on.
> I think it might have something to do on whether they were > built with a suffix or not, when they made the dist. > No, this shouldn't have any influence; the generated rebuild rules invoke $(AUTOMAKE), and that (unless overridden at configure or make runtime), defaults to "automake-${APIVERSION}" (i.e., automake-1.11 for Automake 1.11.x, automake-1.12 for Automake 1.12.x, etc). >> But if the patch legitimately modified some Makefile.am, then you are >> as much as screwed if you do not re-bootstrap with the autotools in a >> controlled fashion nor have the automatic remake rules kick in: the >> Makefile will not be regenerated, which might cause build errors (in >> the best scenario) or leave the built package in an inconsistent >> state. > > Again, the consistency issue is the other way from what you think: if it > always fails, and the patch to Makefile.am always get ignored, it's much > more consistent than it sometimes sticking, and sometimes not. For a > distribution packager that has to troubleshoot errors, that consistency > is gold. > OK, I now get what your use case is. And it's a valid one. But I still think that such timestamp issues due to the patching of generated files should be dealt with by the one doing the patching (be it a program or a person). >> But still, it is conceptually wrong, because it suggests that having >> incompletely specified dependencies is a legitimate way to avoid >> potentially useless rebuilds due to issues in other tools. > > It's conceptually wrong that I need to fix every other package because > upstream ignores most of the best practices ever said about development, > but I still have to deal with it. > > We have a split here: you want a perfect world where nothing that is > conceptually wrong exists; I live in a world where conceptually wrong is > daily bread and I want a weapon against time waste. > >> But OTOH, I certainly do not want to encourage any new use of it: unless >> I'm still missing something fundamental here, AM_MAINTAINER_MODE is >> basically an hack to work around suboptimal practices or brokenness >> in other tools, and we should work toward fixing those rather than >> offering brittle workarounds. > > If that's what you want, fine. Do know that I _will_ fiercely suggest to > developers to use AM_MAINTAINER_MODE([enable]) in their configure.ac. > If that's what you want; I will *not* flag AM_MAINTAINER_MODE for potential removal, nor make plans to remove it, so you can rely on its presence now and in the future. But I might discourage it more prominently in the documentation in the not-so-far future (also, while I don't plan to add runtime warnings for the time being, that might change in the quite-far future). > It does not make a change by default, but it allows us to have a > reproducible build, which is what we really need. Regards, Stefano