On Fri, 21 Sep 2007 08:39:25 -0600, Richi Plana 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? You want to insert another layer between installing system components and making them available system-wide after installation? Or a layer between the depsolver and the transaction set? Like "repo offers libfoo-2.0-1 and libfoo2-2.0-1, and user can choose either one or even both, and decide which to make available to apps"? Or you want packages to switch back and forth automatically between alternative implementations of the same interface? Redundancy instead of reuse. We don't talk about the same problem, I'm afraid. It is beyond my time to extend this thread much further and in pure text form into something completely theoretical that would require fundamental changes to the RPM dependencies system. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
