[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Stefano Lattarini
Date: Fri, 08 Feb 2013 13:26:23 +0100

On 02/08/2013 12:37 AM, Diego Elio Pettenò wrote:
> On 07/02/2013 19:47, Stefano Lattarini wrote:
>> So you want to allow users to disable maintainer-mode rules in every
>> package?
> Yes. Where users here is "distribution packagers".
>> Better risk an extra rebuild than to miss a required one IMVHO.  Or
>> understand why timestamps get mangled, and fix that problem instead of
>> its symptoms (i.e., unnecessary rebuilds, in this case).
> Yes and no. In some cases, the problem we get is that the rebuild only
> happens in some circumstances, and thus the developer is missing it, but
> it happens on the users' systems, and then they report a bug that we
> can't reproduce...
> Basically, I want to have a build failure rather than a build that might
> be wrong.
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?

>> I failed to understand what you're saying here, sorry.  Care to rephrase,
>> or give an example?
> I don't have an example at hand, but let's say this:
>  - you got a package that for whatever reason is completely messed up if
>    generated with automake-1.12, but works fine with 1.9;
>  - when I'm rebuilding it as part of an ebuild (Gentoo's spec files
>    equivalent, give or take), I declare WANT_AUTOMAKE=1.9;
>  - but I'm not rebuilding it in the ebuild;
>  - until I get a patch that I don't check thoroughly and messes up the
>    timestamps;
>  - I still do not rebuild autotools in a controlled fashion;
>  - automake triggers the rebuild, and rebuilds with 1.12;
(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).

>  - I'm screwed.
But if the patch legitimately modified some, 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

> Variations can happen if for instance the configure relies on a variable
> that is not declared with AC_ARG_VAR (way too common).
> Yes, it's all solvable with more attention to details and similar, but
> since we care for stuff to at least behave, --disable-maintainer-mode is
> much nicer _to us_.
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.

Now, I understand that AM_MAINTAINER_MODE has been there for so long, and
its use widespread enough, that I cannot remove it without upsetting a
huge number of people and breaking a lot of packages, no matter how long
a deprecation period I use; so it will stay with us -- you don't need to
worry about that.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]