On Jul 25, 2005, Jakub Jelinek <jakub(a)redhat.com> wrote:
On Sat, Jul 23, 2005 at 09:18:28AM -0400, Arjan van de Ven wrote:
> On Sat, 2005-07-23 at 10:02 -0300, Alexandre Oliva wrote:
> > On Jul 21, 2005, jakub(a)redhat.com wrote:
> >
> > > This update needs to accompany gcc-4.0.1 update.
> > > ---------------------------------------------------------------------
> > > * Thu Jul 21 2005 Jakub Jelinek <jakub(a)redhat.com>
1.5.16.multilib2-2
> > > - rebuilt with GCC 4.0.1.
> >
> > Do you realize this is no longer enough? We need apr-devel rebuilds
> > to accompany GCC version bumps as well.
>
> can we please stop any such idiocities in cross package version
> depencies???? We really really should not have this kind of dependency.
> At all. Ever.
Having to update libtool every time gcc's versioned dir changes
is perhaps something I could live with, but having to update all packages
because of it is silly.
It would be preferrable if libtool could special case the versioned
directories in gcc $CFLAGS -print-search-dirs in the libtool script and
recreate them at runtime using gcc $CFLAGS -print-search-dirs.
This would require significant divergence from upstream libtool.
We really shouldn't be installing a script configured at libtool
build-time in /usr/bin/libtool, since that's what causes such
versioning problems and serves no purpose whatsoever, except lead
people into using libtool in a way it wasn't designed to be used.
Unfortunately, a number of people have already made this mistake, and
they won't even accept it's a mistake.
Maybe we should go ahead and remove /usr/bin/libtool regardless. Then
the problem would just go away.
As for apr-devel, I suspect the need for versioning comes from a
libtool clone that I'm told it contains, but I really don't know, all
I know is that yum reports it can't update to the new testing gcc
because of the dep in apr-devel.
--
Alexandre Oliva
http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}