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, 03:43 AM
Casey Dahlin
 
Default FESCo Proposal for blocking older version of autoconf & automake

Matthias Clasen wrote:

On Mon, 2008-05-05 at 23:28 -0400, Casey Dahlin wrote:



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.





And we do all this work because we have nothing better to do ?
Whats the gain, again ?


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.


--CJD

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 03:44 AM
Matthias Clasen
 
Default FESCo Proposal for blocking older version of autoconf & automake

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.


I don't see any gain here. Just make-work. And I don't see why one
should have to fight for keeping necessary build tools around.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 03:50 AM
"Jerry James"
 
Default FESCo Proposal for blocking older version of autoconf & automake

On Mon, May 5, 2008 at 6:17 PM, Wes Hardaker <wjhns174@hardakers.net> wrote:
> beyond). Fixing a configure.in file to make it portable is often a ton
> of work for a big package. If it wasn't, XEmacs would have updated it's
> configure.in file from 2.13 to something more recent a long long time
> ago ;-)

Actually, we did update it on the 21.5 (beta) branch quite awhile ago.
It's true that the 21.4 (stable) branch has never been updated,
though.
--
Jerry James, also known as james@xemacs.org
http://loganjerry.googlepages.com/

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

On Mon, 2008-05-05 at 23:34 +0100, Richard W.M. Jones wrote:
> On Mon, May 05, 2008 at 06:10:50PM +0200, Ralf Corsepius wrote:
> > How do you call projects who stick with antiquated tools and ignore many
> > years of development? I call them poorly maintained.
>
> 'Mature'?
That would be OK, if these packages "just work", i.e. not force users to
using their

> Actually while I personally tend to use whatever version of
> autoconf is installed for my own stuff,
Hear, hear!

That's the way the autotools are supposed to be used by _developers_.

It may surprise some folks, but it really works without major problems
when packages are using the autotools properly (1000s of packages are
doing so). One occasionally trips a minor issue when one of the
autotools is being upgraded, but nothing actually serious.

It really is simple as: You once need to take the plunge, then things
are really simple.

> I have found a couple of
> upstream projects that use autoconf 2.13 and are opposed to upgrading,
> so that is going to be a problem.
Yes, you will always be able to find projects sticking to antiquated
tools and refusing to accept that they are doing something stupid.

So far, most packages I have come across sticking with autoconf-2.13 are
simply relying on exploiting bugs and undocumented features from
autoconf-2.13 (In autoconf-terms: bugwise-compatible configure scripts).

Several larger packages suffered from such issues, but if maintainers
are willing, these issues can be overcome. Even GCC and almost
everything in src/ (aka. ueberbaum, binutils, newlib, gdb, gdb etc.) has
managed to do so.

Another class of issues is people mixing up "minimum required versions"
with "version to use". This causes some developers to use autoconf-2.13,
even though it would be suitable for autoconf > 2.13 (Popular in
Debian).

Ralf


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

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.

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?

Ralf



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

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.

> 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. Most importantly, gcc is a large
package, so there is a considerable cost to shipping more than one version.

As has been pointed out, this FESCo proposal is mere make-work for no purpose.
It serves only to distract maintainers from doing something useful.

Andrew.

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

Somebody in the thread at some point said:

As has been pointed out, this FESCo proposal is mere make-work for no purpose.
It serves only to distract maintainers from doing something useful.


Another way to look at this is the large amount of havoc old auto*
dependency causes in the wider world... success with cross compile for
example is pretty seriously adversely affected the older the auto* is.


I don't know it should particularly be Fedora maintainers' problem,
although it likely makes trouble there too, but any effort to encourage
the upstreams to work with recent autostuffs is definitely not for "no
purpose" in the bigger-than-Fedora sense.


-Andy

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

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? 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!


> Most importantly, gcc is a large
> package, so there is a considerable cost to shipping more than one version.
>
> As has been pointed out, this FESCo proposal is mere make-work for no purpose.
> It serves only to distract maintainers from doing something useful.
To the same extend as gcc-4.3.0 does - It might have escaped you, but
other distros do have alternative toolchains.

Of cause their would be middle-grounds ... but I don't sense any
interest on your (@RH) part to develope/find one.

Ralf



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 10:57 AM
Jesse Keating
 
Default FESCo Proposal for blocking older version of autoconf & automake

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.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-06-2008, 11:24 AM
Jeroen van Meeuwen
 
Default FESCo Proposal for blocking older version of autoconf & automake

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?

Kind regards,

Jeroen van Meeuwen
-kanarip

--
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 09:08 AM.

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