Packages where EPEL beats EL
Paul Howarth
paul at city-fan.org
Fri Mar 12 20:55:19 UTC 2010
On Fri, 12 Mar 2010 17:32:39 +0000
Mark Chappell <tremble at 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.
More information about the epel-devel-list
mailing list