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 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. > 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. Regards, Stefano
