soname Provides

[Michael Schwendt]

On Thu, 20 Sep 2007 10:06:05 -0600, Richi Plana wrote:

> Storing resources in non-systemwide defaults CAN work assuming that the
> underlying selection system supports it. For example, Java
> implementations can be stored in various subdirectories, but must be
> activated with alternatives. Libraries can be stored in private
> subdirectories if the package updates all user processes LD_LIBRARY_PATH
> environment variables to include them. One advantage of the latter
> approach is that the dynamic loader will search all the paths in
> LD_LIBRARY_PATH for the needed library whereas alternatives uses just
> one. It would be nice if some kind of priority system could be adopted
> (conceptually by rearranging the paths in the variable).

And then you end up with competing implementations of the same library
interface. One with vulnerabilities, the other one with security-fixes.  
One with customisations and several minor releases behind, the other
the latest release with bug-fixes. One built with a complete feature
set, the other stripped down to upstream defaults. RPM dependencies
would need to get much more complex if to cover such differences in
implementations.

That's not something I'd like to see, at least not for system
libraries. Using /etc/ld.so.conf.d/ (not LD_LIBRARY_PATH, which is
empty by default btw) already is dangerous enough, since it can be
used to avoid file conflicts and still insert competing libs into
run-time linker's view. Further, there's no difference between
"Provides" of libs in private paths and system-wide paths. It's too
easy to disable/move the private paths and pull away the libs from the
run-time env.

> So I would agree with your statement with the slight modification that
> the package must actually enable said provisions system-wide.

Only then it may announce itself as being a provider of "something".