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, 02:01 PM
Ankur Sinha
 
Default Calling autoconf in a spec.

Hello,

I need help with a package[0] that needs autoconf to be called before
the build can begin. I've read this draft which addresses the issue[1].
I used the second solution which says:

"When manual modification of configure or Makefile.in for the purpose of
generating a patch is impractical, packagers can create a patch by
regenerating configure and/or Makefile.in to use as input to diff. In
general, autoreconf should not be used for this purpose because it will
regenerate files that probably don't need to be regenerated. "

This fixed the build on my F15, but didn't work on F14. How should I go
about handling this please? Should I just call autoconf in the spec and
be done with it?

Thanks,
Regards,
Ankur
[0] https://bugzilla.redhat.com/show_bug.cgi?id=712624
[1] http://fedoraproject.org/wiki/PackagingDrafts/AutoConf


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

Ankur Sinha <sanjay.ankur@gmail.com> writes:
> I need help with a package[0] that needs autoconf to be called before
> the build can begin. I've read this draft which addresses the issue[1].
> I used the second solution which says:

> "When manual modification of configure or Makefile.in for the purpose of
> generating a patch is impractical, packagers can create a patch by
> regenerating configure and/or Makefile.in to use as input to diff. In
> general, autoreconf should not be used for this purpose because it will
> regenerate files that probably don't need to be regenerated. "

> This fixed the build on my F15, but didn't work on F14. How should I go
> about handling this please? Should I just call autoconf in the spec and
> be done with it?

Sure. As pointed out on the wiki page, that policy is controversial;
you should not feel bound by it. At the same time you should realize
why it's there: the concern is that when autoconf changes versions,
that could unexpectedly break your package. Personally I don't think
that's significantly more likely than changes in any other build tool
breaking your package, but YMMV.

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, ...)

regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-03-2011, 04:48 PM
Sam Varshavchik
 
Default Calling autoconf in a spec.

Tom Lane writes:


Ankur Sinha <sanjay.ankur@gmail.com> writes:
> I need help with a package[0] that needs autoconf to be called before
> the build can begin. I've read this draft which addresses the issue[1].
> I used the second solution which says:

> "When manual modification of configure or Makefile.in for the purpose of
> generating a patch is impractical, packagers can create a patch by
> regenerating configure and/or Makefile.in to use as input to diff. In
> general, autoreconf should not be used for this purpose because it will
> regenerate files that probably don't need to be regenerated. "

> This fixed the build on my F15, but didn't work on F14. How should I go
> about handling this please? Should I just call autoconf in the spec and
> be done with it?

Sure. As pointed out on the wiki page, that policy is controversial;
you should not feel bound by it. At the same time you should realize
why it's there: the concern is that when autoconf changes versions,
that could unexpectedly break your package. Personally I don't think
that's significantly more likely than changes in any other build tool
breaking your package, but YMMV.

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, ...)


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.
Once you understand how autoconf spews out the configure script, and you've
looked at a sufficient number of various configure scripts, figuring out how
to patch it directly, so it does what you want, is not rocket science.


If there was a problem in the makefile, I always found a way to patch the
Makefile /after/ running configure. With a reproducible build, you should
always get the same Makefile after running configure, and that can be
patched at that point. Patching Makefile.in might result in the final
Makefile attempting to rebuild itself via automake, producing a big mess,
but it's always safe to patch the final Makefile.


Even with libtool thrown in the mix, I was always able to find a way to
patch the final scripts themselves, rather then the templates they get
generated from. Finally, all they do is control the resulting build, and
sometimes whatever needs to be fixed, can be fixed by patching the actual
source, itself. If configure is not setting some preprocessor macro
correctly, just patch the define directly into the right header file,
instead of patching configure to do it, and move on with your life.



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-03-2011, 05:31 PM
Tom Lane
 
Default Calling autoconf in a spec.

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.

regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-03-2011, 05:38 PM
drago01
 
Default 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
 
Old 07-03-2011, 08:23 PM
Sam Varshavchik
 
Default Calling autoconf in a spec.

drago01 writes:


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.


Ok, then when you patch configure.in, configure.ac, and/or Makefile.am, be
sure to also specify:


BuildRequires: autoconf=[version]

and

BuildRequires: automake=[version]

in order to have a reproducible build.

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

Ankur Sinha wrote:
> I need help with a package[0] that needs autoconf to be called before
> the build can begin. I've read this draft which addresses the issue[1].
> I used the second solution which says:

> [1] http://fedoraproject.org/wiki/PackagingDrafts/AutoConf

That draft is a draft for a reason. It's complete nonsense.

I recommend just running autoreconf -i -f in the specfile if you need to
change any of the autocrap code.

Kevin Kofler

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

Sam Varshavchik wrote:
> Ok, then when you patch configure.in, configure.ac, and/or Makefile.am, be
> sure to also specify:
>
> BuildRequires: autoconf=[version]
>
> and
>
> BuildRequires: automake=[version]
>
> in order to have a reproducible build.

Nonsense. Even many upstreams do that. (I know I don't. On the autocrap-
using projects I inherited, I just run "autoreconf -i -f" with whatever
version I have on my system and ignore all the warnings.)

Kevin Kofler

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

drago01 wrote:
> Exactly patching generated code is just wrong period.

+1. It's also a violation of the GPL (for GPLed projects), because you
aren't changing the preferred form for modification.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-03-2011, 10:41 PM
Sam Varshavchik
 
Default Calling autoconf in a spec.

Kevin Kofler writes:


Sam Varshavchik wrote:
> Ok, then when you patch configure.in, configure.ac, and/or Makefile.am, be
> sure to also specify:
>
> BuildRequires: autoconf=[version]
>
> and
>
> BuildRequires: automake=[version]
>
> in order to have a reproducible build.

Nonsense. Even many upstreams do that.


Can you translate that. It's nonsense because many upstreams do that?


(I know I don't. On the autocrap-
using projects I inherited, I just run "autoreconf -i -f" with whatever
version I have on my system and ignore all the warnings.)


Sure. You must be able to tell, at a glance, which version of autoconf and
automake were used by upstream, and what the impact will be as a result of
rebuilding with, most likely, Fedora's different version, even before
introducing any patches. I mean, after all, autoconf has such a perfect
record of 100% backwards compatibility, as far as I can remember.


Sounds like a plan to me.

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

Thread Tools




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

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