[Top][All Lists]

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


From: Stefano Lattarini
Date: Sat, 09 Feb 2013 20:20:32 +0100

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, 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 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

>> 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
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.


reply via email to

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