In general a multiple provision of libraries is not well seen in the guidelines (see NX example providing X11 libs). In the case of lapack/atlas atlas provides lapack equivalents which look like they are not covering 100% lapack functionality or that are not compatible. a) ATLAS states that it does not provide a complete LAPACK implementation: http://math-atlas.sourceforge.net/errata.html#completelp b) Packages requiring parts of lapack (be that as build dependencies or run-time dependencies) pull in atlas instead of lapack, see for example bug #214967. While the latter bug (BR) can be worked around at the cost of compatibility to RHEL and older Fedoras, the automatically generated library dependencies will still pull in the wrong lib. Note: I haven't tested this myself, the people that reported issues with lapack/atlas are in the Cc.
I'm aware that ATLAS source code does not provide 100% of lapack functions. For that reason, the build process for the atlas package pulls in the missing functions from lapack so that the provided lapack libs are 100% binary compatible. If you can find a specific example of a function missing from the atlas lapack libraries, please let me know and I will try to fix it.
Michał Bentkowski had reported failure in using atlas-devel for building arpack in bug #214967, but there were no specific details as to what was breaking. Michał could you please outline the issue here? Thanks!
(In reply to comment #2) > Michał Bentkowski had reported failure in using atlas-devel for building arpack > in bug #214967, but there were no specific details as to what was breaking. > Michał could you please outline the issue here? Thanks!
According to my findings in bug 349801, it's a bug in mock. Thus I'm closing this.