On Thu, 2007-09-20 at 17:15 +0200, Michael Schwendt wrote: > On Thu, 20 Sep 2007 06:57:40 -0600, Richi Plana wrote: > > > It's certainly not unheard of for different packages to provide the same > > implementation of an interface. In fact, we should probably start > > thinking of coming up for solutions for such a scenario. > > Technically, the different packages should only offer the same > implementation of an interface if they make it available in a public > place of the run-time environment where it is found by default by all > components which may require a given implementation. General examples > for such places are the dynamic linker's search paths for shared > libraries [1], Perl/Python module directories, and most likely similar > directories for Mono and other programming-language run-time > environments. If, however, they store the implementation in a private > directory, where it doesn't satisfy run-time requirements by default, > they should not advertise the implemented interface [via the RPM > system]. It bears the risk of breaking other packages like with this > Perl module example: http://bugzilla.redhat.com/247113 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). So I would agree with your statement with the slight modification that the package must actually enable said provisions system-wide. I think in Windows (I haven't used Windows in ages so I'm just guessing), some packages use the approach where the library directory is added to the library search path. If that's what's used in mono and the mono packages, then it's probably safe to allow the Provide:. Disclaimer: I don't actually use mono and am just guessing at the packages' implementation. There was a certain beauty and elegance to the /opt/<package>/(bin|lib) system of yore. Too bad it was abandoned rather than integrated/improved. -- Richi Plana -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
