FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 07-03-2011, 08:25 PM
"pinto.elia@gmail.com"
 
Default R: Calling autoconf in a spec.

First of all Sorry for not quoting. It is just for telling an opinion from someone that know the autofu well, almost. For me this idea of patching generated autofu is wrong. if i have to patching the GNU build system there is a reason of course. Which reason is right for a packager ? Imho in many case it is because the build system is incomplete or wrong ( use only autocof for example, but not automake or don't want to use libtool). In any case can be difficult to change some setting without changing the build system. But now is the problem : the new autofu version know now, and not before, that some costruct is problematic or perhaps no, but they give some cryptic error message. In short the right solutinn in a floss env is to patch configure.ac, makefile.am doing thereafter an autoreconf -vfi and reporting the problem upstream. Nothing of different to patch the code is not fhs or if new compiler flag catch an unseen possible error. Ideally an good floss ecosystem should work, and mostly does, in this way, i think. Why this Could be different for the GNU build system ? Thanks for attending. Best regards.
----Messaggio originale----
Da: drago01
Inviato: 03/07/2011, 19:38
A: Development discussions related to Fedora
Oggetto: Re: Calling autoconf in a spec.


On Sun, Jul 3, 2011 at 7:31 PM, Tom Lane <tgl@redhat.com> wrote:
> Sam Varshavchik <mrsam@courier-mta.com> writes:
>> To add to that: I never recall a single instance where I couldn't fix any
>> breakage in someone else's canned configure/makefile scripts without having
>> to rerun autoconf and automake.
>
>> If there was a problem in the configure script, rather than patching
>> configure.ac or configure.in, I simply patched the configure script itself.
>
> Yeah, and the question is why that's a good idea at all, let alone so
> superior as to be policy. *To me it sounds exactly like arguing that you
> should fix a code bug by patching the emitted assembler code, instead of
> touching the C code. *Or fixing a grammar problem by patching bison's
> output file instead of the input .y file. *It just seems uselessly stone
> age. *And it certainly does not yield a patch that you are going to be
> able to submit to upstream.

Exactly patching generated code is just wrong period.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-03-2011, 08:34 PM
Kevin Kofler
 
Default R: Calling autoconf in a spec.

pinto.elia@gmail.com wrote:
> First of all Sorry for not quoting. It is just for telling an opinion from
> someone that know the autofu well, almost. For me this idea of patching
> generated autofu is wrong. if i have to patching the GNU build system
> there is a reason of course. Which reason is right for a packager ? Imho
> in many case it is because the build system is incomplete or wrong ( use
> only autocof for example, but not automake or don't want to use libtool).
> In any case can be difficult to change some setting without changing the
> build system. But now is the problem : the new autofu version know now,
> and not before, that some costruct is problematic or perhaps no, but they
> give some cryptic error message. In short the right solutinn in a floss
> env is to patch configure.ac, makefile.am doing thereafter an autoreconf
> -vfi and reporting the problem upstream. Nothing of different to patch the
> code is not fhs or if new compiler flag catch an unseen possible error.
> Ideally an good floss ecosystem should work, and mostly does, in this way,
> i think. Why this Could be different for the GNU build system ? Thanks for
> attending. Best regards.

+1

FWIW, I think we should actually run autoreconf -i -f in ALL specfiles as a
matter of policy, even if we aren't changing anything, the same way we
require Java JARs to be rebuilt from source.

But all this stuff has already been discussed many times. Please search the
mailing list archives!

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-03-2011, 09:15 PM
Farkas Levente
 
Default R: Calling autoconf in a spec.

On 07/03/2011 10:34 PM, Kevin Kofler wrote:
> FWIW, I think we should actually run autoreconf -i -f in ALL specfiles as a
> matter of policy, even if we aren't changing anything, the same way we
> require Java JARs to be rebuilt from source.

please no!
curently most of the fedora packages can be rebuild on rhel/centos. if
you change this policy most of the packages will NOT rebuild since most
of the new packages requires newer autotools then shipped with rhel/centos!

--
Levente "Si vis pacem para bellum!"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-03-2011, 10:33 PM
"pinto.elia@gmail.com"
 
Default R: Calling autoconf in a spec.

Thanks. But the GNU build system don't require or need this by definition, Regards
----Messaggio originale----
Da: Kevin Kofler
Inviato: 03/07/2011, 22:34
A: devel@lists.fedoraproject.org
Oggetto: Re: R: Re: Calling autoconf in a spec.


pinto.elia@gmail.com wrote:
> First of all Sorry for not quoting. It is just for telling an opinion from
> someone that know the autofu well, almost. For me this idea of patching
> generated autofu is wrong. if i have to patching the GNU build system
> there is a reason of course. Which reason is right for a packager ? Imho
> in many case it is because the build system is incomplete or wrong ( use
> only autocof for example, but not automake or don't want to use libtool).
> In any case can be difficult to change some setting without changing the
> build system. But now is the problem : the new autofu version know now,
> and not before, that some costruct is problematic or perhaps no, but they
> give some cryptic error message. In short the right solutinn in a floss
> env is to patch configure.ac, makefile.am doing thereafter an autoreconf
> -vfi and reporting the problem upstream. Nothing of different to patch the
> code is not fhs or if new compiler flag catch an unseen possible error.
> Ideally an good floss ecosystem should work, and mostly does, in this way,
> i think. Why this Could be different for the GNU build system ? Thanks for
> attending. Best regards.

+1

FWIW, I think we should actually run autoreconf -i -f in ALL specfiles as a
matter of policy, even if we aren't changing anything, the same way we
require Java JARs to be rebuilt from source.

But all this stuff has already been discussed many times. Please search the
mailing list archives!

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-04-2011, 01:01 AM
Ankur Sinha
 
Default R: Calling autoconf in a spec.

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.

I'll see what I can do.

Thanks,
Regards,
Ankur

[1]http://www.redhat.com/archives/fedora-packaging/2008-October/msg00098.html


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-04-2011, 02:37 AM
Toshio Kuratomi
 
Default R: Calling autoconf in a spec.

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.
>
Running autoreconf in the spec is fine.

Running autoreconf manually and producing a patch based on that output is
also fine.

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.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-04-2011, 03:09 AM
Tom Lane
 
Default R: Calling autoconf in a spec.

Kevin Kofler <kevin.kofler@chello.at> writes:
> FWIW, I think we should actually run autoreconf -i -f in ALL specfiles as a
> matter of policy, even if we aren't changing anything,

To what end? If you need to change configure.ac, that's one thing ...
but if you don't, you're just uselessly exposing yourself to risks.

I have very little use for dogmatic one-size-fits-all answers for
packaging in general; but autotools use is an issue where one size
especially doesn't fit all. Sometimes it's fine to use upstream's
script as-is; sometimes you have to modify it, and then you might
either want to patch the input files or patch the generated script.

I'd even agree that for some packages it'd be sensible to always
autoreconf even if you aren't changing the input files, if you know
that you've frequently had to change the inputs in the past and you
expect that to be true again in the future. In that case you might
as well find out sooner rather than later if Fedora's autoconf
changes incompatibly. (I used to do this myself on most of my
packages, but have stopped except for those that ship horrendously
obsolete autoconf outputs ...)

This seems to me to be an area best left to the judgment of the
individual packager, based on what he's dealing with in a
particular package.

regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-04-2011, 04:25 AM
Ralf Corsepius
 
Default R: Calling autoconf in a spec.

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-04-2011, 10:46 AM
"Richard W.M. Jones"
 
Default R: Calling autoconf in a spec.

On Sun, Jul 03, 2011 at 11:09:06PM -0400, Tom Lane wrote:
> Kevin Kofler <kevin.kofler@chello.at> writes:
> > FWIW, I think we should actually run autoreconf -i -f in ALL specfiles as a
> > matter of policy, even if we aren't changing anything,
>
> To what end? If you need to change configure.ac, that's one thing ...
> but if you don't, you're just uselessly exposing yourself to risks.

I suspect Kevin's concern is that someone stuffs some hidden shell
code into ./configure which isn't in configure.ac. (Of the "send all
your private ssh keys to remote host" variety).

This concern has some legitimacy. But OTOH someone could stuff the
same code into configure.ac or Makefile.am, and it's likely very few
people would notice.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-04-2011, 11:21 AM
"pinto.elia@gmail.com"
 
Default R: Calling autoconf in a spec.

Sorry for not quoting. Btw, i in rhel5 have packaged the latest autoconf, automake and libtool in such a way that if installed the packager can use it without upgrading the rhel5 package and without conflict of any sort : not so hard to do with rpm. Dunno if my approch was the best, or if it is really useful. Best regards
----Messaggio originale----
Da: Richard W.M. Jones
Inviato: 04/07/2011, 12:39
A: Development discussions related to Fedora
Cc: ankursinha@fedoraproject.org
Oggetto: Re: Calling autoconf in a spec.



On Sun, Jul 03, 2011 at 11:45:09AM -0400, Tom Lane wrote:
> FWIW, I used to run autoconf during the builds of both the postgresql
> and mysql packages for many years. That eventually became unnecessary
> in both cases, but I don't recall that autoconf changes ever caused me
> any trouble. (gcc, on the other hand, ...)

We've been bitten with very old versions of autoconf (hello, RHEL 5).
In those cases we've had to patch the generated files instead of the
autoconf input files. It's a pain in the derriere doing this.

However this is not a reason not to rerun autoconf. If rerunning
autoconf is going to fail, then it will fail early and obviously.
This problem isn't likely to affect Fedora because Fedora usually has
the latest autotools.

Packagers should use their discretion (as in many other cases).

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 05:13 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org