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