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.). > 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. 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. Experience however tells: Running the autotools inside of specs will fall back at the packager in longer terms and therefore is not advisable. Ralf -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel