On Sat, Feb 28, 2009 at 4:36 AM, Paul Howarth <paul@city-fan.org> wrote:
I do think that filtering these provides is the right thing to do but
I'm not sure about the approach. Whilst it should be fine for a regular
perl module package, it could cause problems for mixed-language
packages where there are other valid provides that should be included
but are not found by the perl provides script. An alternative approach
for such cases would be, e.g.

# don't provide the private XS.so lib
%global _use_internal_dependency_generator 0
%global provfind /bin/sh -c "%__find_provides | grep -v '^XS[.]so'"
%global __find_provides %provfind

Yeah.  I was using as a simple case the filtering needed in perl-Readonly-XS...  Others will be different, e.g. perl-Imager requires a bunch filtered:

perl-Imager ==> CountColor.so()(64bit) 
perl-Imager ==> DynTest.so()(64bit) 
perl-Imager ==> Flines.so()(64bit) 
perl-Imager ==> ICO.so()(64bit) 
perl-Imager ==> Imager.so()(64bit) 
perl-Imager ==> Mandelbrot.so()(64bit) 
perl-Imager ==> SGI.so()(64bit)

The following snippet just filters any .so files under %perl_vendorarch from being run through %__find_provides:

# don't "provide" private Perl libs
%global _use_internal_dependency_generator 0
%global provfind /bin/sh -c "grep -v '%perl_vendorarch.*\\.so$' | %__find_provides"
%global __find_provides %provfind

Looking at just the packages installed on my system, I see 208 '*perl*' packages providing shared libs; for 432 .so's.

http://fedorapeople.org/~cweyl/impacted_packages
http://fedorapeople.org/~cweyl/private_libs

                       -Chris
--
Chris Weyl
Ex astris, scientia