On Jul 25, 2005, Jakub Jelinek <jakub@xxxxxxxxxx> 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@xxxxxxxxxx wrote: >> > >> > > This update needs to accompany gcc-4.0.1 update. >> > > --------------------------------------------------------------------- >> > > * Thu Jul 21 2005 Jakub Jelinek <jakub@xxxxxxxxxx> 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@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list