Disable RPM's autoprovide function

[Chris Adams]

Once upon a time, Stewart Adam <s.adam at diffingo.com> said:
> A bug report at Livna (#1741) pointed out that the
> xorg-x11-drv-nvidia-libs-32bit package is pulled in over mesa-libGL.i386
> when the 32-bit library "libGL.so.1" is required on x86_64 (in the
> user's case, it was while installing wine). libGL.so.1 is automatically
> provided because of the scripts that RPM runs at the end of a build - Is
> there some way to override this or disable it so that libGL.so.1 is only
> provided by mesa-libGL?

This comes up with perl modules regularly (as someone else has pointed
to the hack used there).

Why does RPM (well, the scripts used in rpm-build) look in non-standard
directories?  Shouldn't libraries only be automatically "provided" if
they are in standard library directories, perl modules should only be
"provided" if they are in standard perl directories, etc.?

This would complicate automatic requires for these packages.  E.g. a
perl app that has a private module Foo::Bar would automatically get a
requires perl(Foo::Bar), but maybe the process could be something like:

(a) find standard directory provides
(b) find non-standard directory provides
(c) find all requires
(d) auto-filter (b) from (c)

There'd need to be a way for packages to add directories to the standard
list in a spec file (for packages that have their own library
directories but add them to /etc/ld.so.conf.d for example), and maybe
take -rpath info into consideration for libraries (and use lib "blah" in
perl, and so on for other auto-req-prov things).

Maybe at least rpmlint could warn about possible problems.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.