FESCo Proposal for blocking older version of autoconf & automake
 

I received the following proposal from Karsten Hopp, which he would like
FESCo to make a decision on during this week's meeting (2008-05-08).
I'm forwarding it to the list, so that people can weigh-in on it.

---

We are currently shipping an insane number of compatibility autofoo
packages which haven't seen any upstream maintenance for many years:

autoconf213-2.13-18.fc8.noarch.rpm (9 years)
automake14-1.4p6-15.fc7.noarch.rpm (6 years)
automake15-1.5-23.noarch.rpm (7 years)
automake16-1.6.3-14.noarch.rpm (6 years)
automake17-1.7.9-11.noarch.rpm (4 1/2 years)

PROPOSAL: I'd like to keep just the following packages and would like to
have release engineering to block the older packages from Rawhide:
autoconf-2.61-10.fc9.noarch.rpm
automake-1.10.1-2.noarch.rpm

This is the complete list of rawhide packages requiring those ancient
autofoo packages, it is rather short and it should be doable to convert
those packages to current autofoo:

automake14 ax25-apps-0.0.6-2.fc9.src.rpm
automake14 gdk-pixbuf-0.22.0-36.fc9.src.rpm
automake14 glib-1.2.10-29.fc9.src.rpm
automake14 gtk+-1.2.10-61.fc9.src.rpm
automake14 sgml-common-0.6.3-23.fc9.src.rpm
automake14 WindowMaker-0.92.0-17.fc9.src.rpm

automake15 nss_db-2.2-40.fc9.src.rpm

automake16 kyum-0.7.5-11.fc9.src.rpm
automake16 qalculate-kde-0.9.6-5.fc9.src.rpm
automake16 sinjdoc-0.5-6.fc9.src.rpm

automake17 cegui-0.5.0b-7.fc9.src.rpm
automake17 ekg2-0.1.1-4.fc9.src.rpm
automake17 gtk2-2.12.9-5.fc9.src.rpm
automake17 nautilus-open-terminal-0.9-2.fc9.src.rpm

autoconf213 esc-1.0.1-9.fc9.src.rpm
autoconf213 glib-1.2.10-29.fc9.src.rpm
autoconf213 gtk+-1.2.10-61.fc9.src.rpm
autoconf213 pam_smb-1.1.7-8.2.2.src.rpm
autoconf213 xdvik-22.84.13-17.fc9.src.rpm

Maintainers are encouraged to switch to more recent releases of the
autoconf tools and/or work with upstream to get this done. They also
should make sure if it is really necessary to run p.e. automake at all
during the build process.

Later,
/B
--
Brian Pepple <bpepple@fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

FESCo Proposal for blocking older version of autoconf & automake
 

Brian Pepple wrote:

I received the following proposal from Karsten Hopp, which he would like
FESCo to make a decision on during this week's meeting (2008-05-08).
I'm forwarding it to the list, so that people can weigh-in on it.

---

We are currently shipping an insane number of compatibility autofoo
packages which haven't seen any upstream maintenance for many years:



<snip>


autoconf213-2.13-18.fc8.noarch.rpm (9 years)
automake14-1.4p6-15.fc7.noarch.rpm (6 years)
automake15-1.5-23.noarch.rpm (7 years)
automake16-1.6.3-14.noarch.rpm (6 years)
automake17-1.7.9-11.noarch.rpm (4 1/2 years)

PROPOSAL: I'd like to keep just the following packages and would like to
have release engineering to block the older packages from Rawhide:
autoconf-2.61-10.fc9.noarch.rpm
automake-1.10.1-2.noarch.rpm




This is the complete list of rawhide packages requiring those ancient
autofoo packages, it is rather short and it should be doable to convert
those packages to current autofoo:

automake14 ax25-apps-0.0.6-2.fc9.src.rpm
automake14 gdk-pixbuf-0.22.0-36.fc9.src.rpm
automake14 glib-1.2.10-29.fc9.src.rpm
automake14 gtk+-1.2.10-61.fc9.src.rpm
automake14 sgml-common-0.6.3-23.fc9.src.rpm
automake14 WindowMaker-0.92.0-17.fc9.src.rpm

automake15 nss_db-2.2-40.fc9.src.rpm

automake16 kyum-0.7.5-11.fc9.src.rpm
automake16 qalculate-kde-0.9.6-5.fc9.src.rpm
automake16 sinjdoc-0.5-6.fc9.src.rpm

automake17 cegui-0.5.0b-7.fc9.src.rpm
automake17 ekg2-0.1.1-4.fc9.src.rpm
automake17 gtk2-2.12.9-5.fc9.src.rpm
automake17 nautilus-open-terminal-0.9-2.fc9.src.rpm

autoconf213 esc-1.0.1-9.fc9.src.rpm
autoconf213 glib-1.2.10-29.fc9.src.rpm
autoconf213 gtk+-1.2.10-61.fc9.src.rpm
autoconf213 pam_smb-1.1.7-8.2.2.src.rpm
autoconf213 xdvik-22.84.13-17.fc9.src.rpm

Maintainers are encouraged to switch to more recent releases of the
autoconf tools and/or work with upstream to get this done. They also
should make sure if it is really necessary to run p.e. automake at all
during the build process.

Later,
/B



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

FESCo Proposal for blocking older version of autoconf & automake
 

<ignore previous nonsense reply I accidentially did ctrl+enter instead of just
enter>

Brian Pepple wrote:

I received the following proposal from Karsten Hopp, which he would like
FESCo to make a decision on during this week's meeting (2008-05-08).
I'm forwarding it to the list, so that people can weigh-in on it.

---

We are currently shipping an insane number of compatibility autofoo
packages which haven't seen any upstream maintenance for many years:

autoconf213-2.13-18.fc8.noarch.rpm (9 years)
automake14-1.4p6-15.fc7.noarch.rpm (6 years)
automake15-1.5-23.noarch.rpm (7 years)
automake16-1.6.3-14.noarch.rpm (6 years)
automake17-1.7.9-11.noarch.rpm (4 1/2 years)

PROPOSAL: I'd like to keep just the following packages and would like to
have release engineering to block the older packages from Rawhide:
autoconf-2.61-10.fc9.noarch.rpm
automake-1.10.1-2.noarch.rpm



This gets a big +1 from me


This is the complete list of rawhide packages requiring those ancient
autofoo packages, it is rather short and it should be doable to convert
those packages to current autofoo:

automake17 cegui-0.5.0b-7.fc9.src.rpm


Thats mine now a days, but I have no problem with fixing this.


They also
should make sure if it is really necessary to run p.e. automake at all
during the build process.



Yes, quite often when adding a simple -lfoo or something like that its quite
easy to patch both the .ac / .am file as the generated files, which is often
better as regenerating autoxxx generated files on old unmaintained .ac / .am
files can often (silently) introduce all kind of interesting (new) bugs.


So its really much better to try and not regenerate autoxxx files during the
build ever. There is a reason why these files are part of the tarbal and not
regenerated automatically during a ./configure && make even when the tools to
regenerate them are present.


Regards,

Hans

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

FESCo Proposal for blocking older version of autoconf & automake
 

2008/5/5 Brian Pepple <bpepple@fedoraproject.org>:
> This is the complete list of rawhide packages requiring those ancient
> autofoo packages, it is rather short and it should be doable to convert
> those packages to current autofoo:
[snip]
> autoconf213 xdvik-22.84.13-17.fc9.src.rpm
>

This one is mine. xdvik is a generally quite crufty piece of software
that we still need to ship, but i am happy to get it building with
newer autoconf (but it won't happen over night) as I agree with the
spirit of the proposal.

Jonathan.

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

FESCo Proposal for blocking older version of autoconf & automake
 

On 05/05/2008 10:59 AM, Brian Pepple wrote:

I received the following proposal from Karsten Hopp, which he would like
FESCo to make a decision on during this week's meeting (2008-05-08).
I'm forwarding it to the list, so that people can weigh-in on it.

---

We are currently shipping an insane number of compatibility autofoo
packages which haven't seen any upstream maintenance for many years:

autoconf213-2.13-18.fc8.noarch.rpm (9 years)
automake14-1.4p6-15.fc7.noarch.rpm (6 years)
automake15-1.5-23.noarch.rpm (7 years)
automake16-1.6.3-14.noarch.rpm (6 years)
automake17-1.7.9-11.noarch.rpm (4 1/2 years)

PROPOSAL: I'd like to keep just the following packages and would like to
have release engineering to block the older packages from Rawhide:
autoconf-2.61-10.fc9.noarch.rpm
automake-1.10.1-2.noarch.rpm

This is the complete list of rawhide packages requiring those ancient
autofoo packages, it is rather short and it should be doable to convert
those packages to current autofoo:


This is only the complete list of packages that currently BuildRequire
it in their spec. Not the packages that ever BuildRequire them.


The entire mozilla stack requires autoconf213 for configure.in hacking.
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=104642


Unless someone steps up and does the work to get this upstream properly,
I am afraid I, along with some of the mozilla upstream developers, will
no longer be able to use rawhide if we drop autoconf213 from it.


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

FESCo Proposal for blocking older version of autoconf & automake
 

On Mon, 2008-05-05 at 10:59 -0400, Brian Pepple wrote:
> I received the following proposal from Karsten Hopp, which he would like
> FESCo to make a decision on during this week's meeting (2008-05-08).
> I'm forwarding it to the list, so that people can weigh-in on it.
>
> ---
>
> We are currently shipping an insane number of compatibility autofoo
> packages which haven't seen any upstream maintenance for many years:
>
> autoconf213-2.13-18.fc8.noarch.rpm (9 years)
> automake14-1.4p6-15.fc7.noarch.rpm (6 years)
> automake15-1.5-23.noarch.rpm (7 years)
> automake16-1.6.3-14.noarch.rpm (6 years)
> automake17-1.7.9-11.noarch.rpm (4 1/2 years)

> PROPOSAL: I'd like to keep just the following packages and would like to
> have release engineering to block the older packages from Rawhide:
> autoconf-2.61-10.fc9.noarch.rpm
> automake-1.10.1-2.noarch.rpm
+1

This step is way over due. It also will teach maintainers not run the
autotools while building.

Ralf



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

FESCo Proposal for blocking older version of autoconf & automake
 

On Mon, 2008-05-05 at 11:36 -0400, Christopher Aillon wrote:
> On 05/05/2008 10:59 AM, Brian Pepple wrote:

> Unless someone steps up and does the work to get this upstream properly,
> I am afraid I, along with some of the mozilla upstream developers, will
> no longer be able to use rawhide if we drop autoconf213 from it.
This is a non-issue if upstream uses the autotools properly, i.e. is
shipping pre-generated files and doesn't run them while building.

Ralf


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

FESCo Proposal for blocking older version of autoconf & automake
 

On Mon, 2008-05-05 at 17:48 +0200, Ralf Corsepius wrote:

>
> This step is way over due. It also will teach maintainers not run the
> autotools while building.

Thats your personal preference. No need to force that on all of us.

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

FESCo Proposal for blocking older version of autoconf & automake
 

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.

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

FESCo Proposal for blocking older version of autoconf & automake
 

On Mon, 2008-05-05 at 11:57 -0400, Matthias Clasen wrote:
> On Mon, 2008-05-05 at 17:48 +0200, Ralf Corsepius wrote:
>
> >
> > This step is way over due. It also will teach maintainers not run the
> > autotools while building.
>
> Thats your personal preference.

Your liberty to think this.

> No need to force that on all of us.

How do you call SW that relies upon x years old bugs?
I call it poorly maintained.

How do you call projects who stick with antiquated tools and ignore many
years of development? I call them poorly maintained.

Or differently: Upstream projects which stick with these antiquated
versions are as poorly maintained and dead as projects written in KnR or
projects staying with gtk-1. - These projects have had many years to
update their code ... and failed. Now they've got to learn the hard way.


Ralf



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