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. I think it might have something to do on whether they were built with a suffix or not, when they made the dist. > 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. > 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. It does not make a change by default, but it allows us to have a reproducible build, which is what we really need. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
