R: Re: Calling autoconf in a spec.

[Ankur Sinha]

On Mon, 2011-07-04 at 06:25 +0200, Ralf Corsepius wrote:
> On 07/04/2011 04:37 AM, Toshio Kuratomi wrote:
> > On Mon, Jul 04, 2011 at 06:31:18AM +0530, Ankur Sinha wrote:
> >> Hi folks,
> >>
> >> Thanks all for the input. I didn't realize the subject was *this*
> >> controversial. I did find the other discussion thread[1] which was aimed
> >> at completing the draft I had linked to, and as you'll notice it was
> >> inconclusive. I was hoping something had changed (the thread dates back
> >> to 2008).
> >>
> >> I do believe in patching configure.in, and Makefile.am and the rest, but
> >> this package seems a little out of my scope which is why I was thinking
> >> of running autoreconf in the spec.
> 
> Well, without wanting to be disrespectful - The way this sentence is 
> formulated indicates you to not have much experience with the autotools 
> (One detail: The convention to use "configure.in" was deprecated ca. 10 
> years ago.).
> 

I don't :)

I know how to autotoolize a project etc., but I generally run to someone
with more experience when I run into trouble (like this time) ;)

> > Running autoreconf in the spec is fine.
>  >
>  > Running autoreconf manually and producing a patch based on that output is
>  > also fine.
> 
> Only if the maintainer knows what he is doing.

I've already mentioned that this worked for f15 and broke for f14 (my
reviewer tried to build it on f14 and came across this)

> 
> The risk of breaking something only is moderate, if upstreams actively 
> maintain and test their autotools source against different versions of 
> the autotools, if there sources are properly written or if the 
> difference between the autotool-versions upstreams use and the packager 
> uses are fairly small.
> 
> In all other cases, esp. in complex/larger packages and esp. with old 
> packages using outdated versions of the autotools, the risks of breaking 
> something is fairly high (much higher than most unexperienced users will 
> expect).
> 
> > The question hasn't come before the fpc in a while (and we have different
> > members now) but the draft you linked to did not have the votes to pass the
> > last time it came up.
> 
> The rule of thumb should be: "If maintainers know what they are doing 
> and are able to verify it doesn't break a package", they can feel free 
> to apply either approach.

Well, it's working for the time being. I'll probably know autotools
better by the time it decides to break. 

> 
> Experience however tells: Running the autotools inside of specs will 
> fall back at the packager in longer terms and therefore is not advisable.
> 
> Ralf


-- 
Thanks, 
Regards,
Ankur: "FranciscoD"

http://fedoraproject.org/wiki/User:Ankursinha
http://dodoincfedora.wordpress.com/