soname Provides

[Richi Plana]

On Fri, 2007-09-21 at 10:14 +0200, Michael Schwendt wrote:
> 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.

I don't see that as a problem of the system but the installed software.
If anything, that's where the underlying selection mechanism might be
useful. Vulnerabilities and other bugs are problems that need to be
fixed. If an update arrives to fix a vulnerability, then I suggest it be
installed with a higher priority than any other on the system, but if
applications insist on using their buggy version, then that should be
taken up with the application provider.

Why throw out the baby with the bathwater?

> 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.

No, I didn't say it should be the only mechanism, but I believe there's
a certain place for it. Support for it just has to be good. So far, the
scenarios you've painted are due more to buggy implementations than
anything to do with the strategy or philosophy of having multiple
implementations on the system.

Having alternative code (whether it be several different JVM's on a
machine, or several implementations of an MP3 codec) isn't bad per se.
They just have to be supported properly by the system because anything
it can't handle, the user ends up tweaking. Depending on how advanced
the system is that's handling the multiple implementation subsystem,
some users (advanced ones) might actually be alright (and in fact be
more productive) with it, but others might not. But, again, that's a
problem with the implementation that we, as software developers, can
work on.
--

Richi Plana