Once again... this is biting us too so we usually add the AM_MAINTAINER mode ourselves. This scenario is 100% recognizable and a major source of problems for us. Immanuel
On Fri, Feb 8, 2013 at 12:37 AM, Diego Elio Pettenò <flamee...@flameeyes.eu>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. > > > 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; > - I'm screwed. > > 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_. > > -- > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ > >
