On Fri, 12 Mar 2010 17:32:39 +0000
Mark Chappell <tremble(a)tremble.org.uk> wrote:
Stephen John Smoogen wrote:
> Ok if my cave man hacking attempts were correct then this is the
> list of things that in EPEL beats EL-5 stuff:
>
> Looking up all competing providers
> Got all the potential problems, checking them
> ==================================================================
> lapack-devel-3.0-37.el5.x86_64 requires liblapack.so.3()(64bit)
> epel wins with atlas
> atlas - epel
> lapack - el5
That liblapack.so.3 is tucked away in /usr/lib64/atlas/ and isn't on
the library path by default IIRC.
It shouldn't be providing liblapack.so.3 at all; the bogus provide can
be filtered out by doing something like this:
# Don't "provide" our private libs, or generate doc-file dependencies
%global _use_internal_dependency_generator 0
%global docfilt perl -p -e 's|%{_docdir}/%{name}-%{version}\\S+||'
%global so_filt grep -v '%{_libdir}/atlas/.*$'
%global __deploop() while read FILE; do /usr/lib/rpm/rpmdeps -%{1} ${FILE}; done |
/bin/sort -u
%global __find_provides /bin/sh -c "%{so_filt} | %{__deploop P}"
%global __find_requires /bin/sh -c "%{docfilt} | %{__deploop R}"
This is how the filtering macros described at
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
work, but they're only available in recent Fedora releases.
Paul.