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 05-06-2008, 11:44 AM
Karsten Hopp
 
Default FESCo Proposal for blocking older version of autoconf & automake

Jeroen van Meeuwen wrote:

Jesse Keating wrote:

On Mon, 2008-05-05 at 23:43 -0400, Casey Dahlin wrote:
The gain is we decide what to keep and what not to keep based on who
actually is willing to fight to keep it around rather than whoever
feels like complaining on devel list. Its a corollary to "its easier
to apologize than to ask permission," the people who notice the
change are a tiny and far more important subset than the people who
will complain ahead of time.


It doesn't account for the developers who will have failures, notice we
don't package a version of autoconf anymore and say "Screw that" and
move to some other development platform which does support what they
need.




My $.02 worth of thoughts:

One could imagine a policy in which new packages using these tools would
not be accepted per-se, while the tools would still be available,
packaged, for those other packages and developers that need it.


Does such, or something similar, make sense?



Such a policy would be ok with me. The whole intention for this proposal was
to disencourage usage of the old tools, not to force maintainers to rewrite their
configure scripts immediately or use another distribution.
Nonetheless maintainers of forementioned packages should check if it is
necessary to run autofoo during the build. Most of the times it isn't and if I
remember correctly even I am guilty of doing this due to laziness and/or time
constraints.

Karsten

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 12:12 PM
Andrew Haley
 
Default FESCo Proposal for blocking older version of autoconf & automake

Ralf Corsepius wrote:
> On Tue, 2008-05-06 at 09:54 +0100, Andrew Haley wrote:
>> Ralf Corsepius wrote:
>>> On Mon, 2008-05-05 at 17:50 +0100, Andrew Haley wrote:
>>>> Christopher Aillon wrote:
>>>>> On 05/05/2008 11:48 AM, Ralf Corsepius wrote:
>>>>>> This step is way over due. It also will teach maintainers not run the
>>>>>> autotools while building.
>>>>> It will also teach maintainers not to use Fedora for doing upstream work.
>>>> I agree. This proposal seems to be all pain for no gain.
>>> The fact Fedora ships gcc-4.3.0 is all pain for no gain.
>> Certainly not! There's been a bunch of useful improvements, as you'll see
>> on the gcc web page.
> No disagreement, but .. there also are a lot of changes, which require
> developers to change/update/rework their sources.
>
>>> Please add versions of gcc of all active GCC-branches, such that people
>>> can continue to use f77 and c++'s backward stuff.
>>>
>>> Also consider adding a version of gcc which ships still supports libg++.
>>>
>>> Do you sense the insanity?
>> I don't think this is a relevant comparison.
> Why?

It's in the following sentence. It really helps to read a message before
beginning to reply.

> You are using a dead piece of SW called autoconf-2.13, others are
> using a dead piece of SW called gcc-2.7.2/egcs or libg++ or gcc-3.x.-
>
> The only difference is RH playing nice to people using outdated
> autotools and pushing around people using outdated c/c++ code or
> features/miss-features from older gcc's.
>
> In fact, you are aggressively forcing Fedora based developers to rework
> their c/c++/fortran-code or to quit using Fedora, but you refuse to fix
> your autotools-code? Double-standards!

Even if all of that were true, it wouldn't change the fact that this
proposal is all pain for no gain.

>> Most importantly, gcc is a large
>> package, so there is a considerable cost to shipping more than one version.

Andrew.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 12:24 PM
Ralf Corsepius
 
Default FESCo Proposal for blocking older version of autoconf & automake

On Mon, 2008-05-05 at 13:56 -0500, Jason L Tibbitts III wrote:
> >>>>> "RC" == Ralf Corsepius <rc040203@freenet.de> writes:
>
> RC> This is a non-issue if upstream uses the autotools properly,
> RC> i.e. is shipping pre-generated files and doesn't run them while
> RC> building.
>
> The upstream developers still need to have autoconf213 in order to
> actually develop the package, though.
Correct - Either they will have to distribute "their autotools
themselves" (Which, for example GCC does.) or switch the version of
autotools they are using.

On a wider scale, as long as vendors ship modified autotools, major
projects will have to do so in any case.

> Hence they still need to get
> that old version of the package from somewhere. I see no reason why
> Fedora shouldn't simply provide it for them.
cf. above. From an upstream perspective, unless these tools are 100%
genuine FSF sources, these tools are useless.

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 01:41 PM
"Jonathan Underwood"
 
Default FESCo Proposal for blocking older version of autoconf & automake

2008/5/6 Casey Dahlin <cjdahlin@ncsu.edu>:
> In light of this, I have a proposal:
>
> We fix our specs to not use autoconf, and remove the old versions as
> stated, but we keep them around, perhaps in another branch in CVS or simply
> removed from the F10 tag. Then we just wait for complaints. If someone comes
> in and says "I was actively using that" we can just slap it back in. After
> one release cycle we can flush the rest.

*I was actively using that*

Building xdvik and also a patched version to add in japanese support,
and also to force the build to use system installed libraries rather
than to build against locally bundled versions requires some hacking
and autoconfery. Yes, I am getting upstream fixing aspects of this,
and yes I will look at moving to a later autoconf, but please don't
remove the previous versions of autoconf or ban autotools from the
spec files.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 01:54 PM
Toshio Kuratomi
 
Default FESCo Proposal for blocking older version of autoconf & automake

Jeroen van Meeuwen wrote:

Jesse Keating wrote:

On Mon, 2008-05-05 at 23:43 -0400, Casey Dahlin wrote:
The gain is we decide what to keep and what not to keep based on who
actually is willing to fight to keep it around rather than whoever
feels like complaining on devel list. Its a corollary to "its easier
to apologize than to ask permission," the people who notice the
change are a tiny and far more important subset than the people who
will complain ahead of time.


It doesn't account for the developers who will have failures, notice we
don't package a version of autoconf anymore and say "Screw that" and
move to some other development platform which does support what they
need.




My $.02 worth of thoughts:

One could imagine a policy in which new packages using these tools would
not be accepted per-se, while the tools would still be available,
packaged, for those other packages and developers that need it.


Does such, or something similar, make sense?


No.

The packager should not have to use the autotools normally. So during
package review, what version of autotools is necessary might not come
up. Only when a problem is discovered that requires changing the
configure.in/ac or Makefile.am will the version of autotools start
mattering to the packager.


-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 02:02 PM
Toshio Kuratomi
 
Default FESCo Proposal for blocking older version of autoconf & automake

Karsten Hopp wrote:

Jeroen van Meeuwen wrote:

Jesse Keating wrote:

On Mon, 2008-05-05 at 23:43 -0400, Casey Dahlin wrote:
The gain is we decide what to keep and what not to keep based on who
actually is willing to fight to keep it around rather than whoever
feels like complaining on devel list. Its a corollary to "its easier
to apologize than to ask permission," the people who notice the
change are a tiny and far more important subset than the people who
will complain ahead of time.


It doesn't account for the developers who will have failures, notice we
don't package a version of autoconf anymore and say "Screw that" and
move to some other development platform which does support what they
need.




My $.02 worth of thoughts:

One could imagine a policy in which new packages using these tools
would not be accepted per-se, while the tools would still be
available, packaged, for those other packages and developers that need
it.


Does such, or something similar, make sense?



Such a policy would be ok with me. The whole intention for this proposal
was
to disencourage usage of the old tools, not to force maintainers to
rewrite their

configure scripts immediately or use another distribution.
Nonetheless maintainers of forementioned packages should check if it is
necessary to run autofoo during the build. Most of the times it isn't
and if I
remember correctly even I am guilty of doing this due to laziness and/or
time

constraints.

The problem with talking about removing these packages is that the
packages may not need to run the autotools during build at present but
that doesn't mean they don't have to be run at some indefinite point in
the future.


For release 1.0-1.4 of libfoo, upstream didn't require any patching so
everything worked fine. In release 1.5, upstream made a mess of how
they create and deploy some utilities built with libfoo. In order to
fix this, you have to patch the configure.ac and Makefile.am. Suddenly
you need to have the autotools to be able to build.


(Note: whether you run the autotools from within the spec file or run
them locally and then include the diff with the SRPM, you may still need
to have matching versions of the autotools available to make everything
work. Getting this right needs to do a lot of upstream education before
it can be removed from the distro.)


-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 02:07 PM
Wes Hardaker
 
Default FESCo Proposal for blocking older version of autoconf & automake

>>>>> On Mon, 5 May 2008 21:50:30 -0600, "Jerry James" <loganjerry@gmail.com> said:

JJ> Actually, we did update it on the 21.5 (beta) branch quite awhile ago.
JJ> It's true that the 21.4 (stable) branch has never been updated,
JJ> though.

Which means anyone working on the stable version and adding patches to
that still needs the older autoconf (which was my point).

21.4 has been the stable branch for a very very long time...
--
"In the bathtub of history the truth is harder to hold than the soap,
and much more difficult to find." -- Terry Pratchett

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 02:09 PM
Wes Hardaker
 
Default FESCo Proposal for blocking older version of autoconf & automake

>>>>> On Mon, 5 May 2008 21:50:30 -0600, "Jerry James" <loganjerry@gmail.com> said:

JJ> Actually, we did update it on the 21.5 (beta) branch quite awhile ago.
JJ> It's true that the 21.4 (stable) branch has never been updated,
JJ> though.

In second thought, that really brings up one of my primary points:
People don't like upgrading autoconf version usage on old branches
because it brings about unknown effects a lot of the time. IE, it's
simply not safe to do without heavy understanding and testing. It's
like adding a feature; you don't do it on stable releases because it
can't be trusted.

And thus, if we want developers to use fedora we should distribute
multiple versions of the development tools when version updates have
potentially large ramifications.
--
"In the bathtub of history the truth is harder to hold than the soap,
and much more difficult to find." -- Terry Pratchett

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 02:37 PM
Matej Cepl
 
Default FESCo Proposal for blocking older version of autoconf & automake

On Mon, 05 May 2008 11:33:11 -0700, Alan scripst:
> I build a fair amount of software that is not in the repository. Some
> of it requires crufty old versions of various toolkits. Having those
> toolkits go away makes it much harder to get this packages to run. If I
> have an older version that does compile, I can determine if it even
> works at all. (Which happens far too often for me. *cough* *cough*
> numerix *cough*)

So, OK, why don't we carry gcc 2.95? There are still many pieces of
software which needs it.

Matěj

--
The content of this message is licensed under a Creative Commons
Attribution 3.0 License, Some Rights Reserved.
http://creativecommons.org/licenses/by/3.0/us/

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 02:46 PM
Stepan Kasal
 
Default FESCo Proposal for blocking older version of autoconf & automake

Hi,

On Mon, May 05, 2008 at 06:53:59PM +0200, Ralf Corsepius wrote:
> On Mon, 2008-05-05 at 12:33 -0400, Christopher Aillon wrote:
> > Or if autotools maintainers would stop changing the interface so
> > freaking often, this wouldn't be a problem either....
> Apparently you don't have much clues about the autotools.
>
> They did not change the "interface so often".
>
> There has been one big interface change: It occurred between
> autoconf-2.13 and autoconf-2.50 - Many years ago.

well, there was also the change in Automake 1.4 -> 1.5, which
happened after that, and then the "stabilization period" for "new"
automake until, say, 1.8.

So it is about 7 years ago since the last interface change and
we can say that Autotools are really stable and mature for at least 4
years.

What _is_ the problem, is that many projects use an undocumented
internals, instead of requesting an enhancement.
And _that_ kind of hacks break very easily with a new release.

Stepan

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




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

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