[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AM_MAINTAINER_MODE
From: |
Diego Elio Pettenò |
Subject: |
Re: AM_MAINTAINER_MODE |
Date: |
Fri, 08 Feb 2013 13:40:09 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 |
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
address@hidden — http://blog.flameeyes.eu/
- Inconsistencies in boolean parameters, Diego Elio Pettenò, 2013/02/07
- Re: Inconsistencies in boolean parameters, Stefano Lattarini, 2013/02/07
- AM_MAINTAINER_MODE, Diego Elio Pettenò, 2013/02/07
- Re: AM_MAINTAINER_MODE, Stefano Lattarini, 2013/02/07
- Re: AM_MAINTAINER_MODE, Bob Friesenhahn, 2013/02/07
- Re: AM_MAINTAINER_MODE, Diego Elio Pettenò, 2013/02/07
- Re: AM_MAINTAINER_MODE, Stefano Lattarini, 2013/02/08
- Re: AM_MAINTAINER_MODE,
Diego Elio Pettenò <=
- Re: AM_MAINTAINER_MODE, Stefano Lattarini, 2013/02/09
- Re: AM_MAINTAINER_MODE, immanuel litzroth, 2013/02/08
- Re: AM_MAINTAINER_MODE, Russ Allbery, 2013/02/08
- Re: AM_MAINTAINER_MODE, Ineiev, 2013/02/09
- Re: AM_MAINTAINER_MODE, Russ Allbery, 2013/02/09
- Re: AM_MAINTAINER_MODE, Bob Proulx, 2013/02/09
- Re: AM_MAINTAINER_MODE, Russ Allbery, 2013/02/09
- Re: AM_MAINTAINER_MODE, Bob Friesenhahn, 2013/02/09
- Re: AM_MAINTAINER_MODE, Bob Proulx, 2013/02/09
- Re: AM_MAINTAINER_MODE, immanuel litzroth, 2013/02/08