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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
