On Sun, Jan 4, 2009 at 1:53 PM, Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > But this is in no way a complete regression test. I'm quite frankly not as competent as I would like to be with regard to runtime linker logic. So the issue may not be as dire as it could be...if the affected system in the bugreport is suffering due to local linker logic reconfiguration. Jury is out on that. But I do think its somewhat problematic in our packaging that lapack and atlas expose the same provides. F10: repoquery --whatprovides liblapack.so.3 atlas-0:3.6.0-15.fc10.i386 atlas-3dnow-0:3.6.0-15.fc10.i386 atlas-sse-0:3.6.0-15.fc10.i386 atlas-sse2-0:3.6.0-15.fc10.i386 lapack-0:3.1.1-4.fc10.i386 Does yum prefer to install atlas over lapack when looking to fill liblapack.so.3 deps? Is that a problem for applications which are compiled against lapack but not atlas at build time? This is the more general problem that worries me, Its probably a corner case in the dependency resolution space that you can only get to if you start from a pathologically broken starting point..like forcibly removing lapack and atlas from your system, then attempting to install something qhich requires that library. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
