On Thu, 2007-09-20 at 06:57 -0600, Richi Plana wrote:
On Thu, 2007-09-20 at 09:11 +0200, Alexander Larsson wrote:
On Thu, 2007-09-20 at 01:29 +0200, Michael Schwendt wrote:
Is it intentional and safe for these packages to provide these Mono capabilities? Are the pairs of packages, which provide exactly the same things, interchangable at run-time? You know what can happen when Yum resolves a dependency by pulling in the pkg with the shortest name...
I guess this is because some mono app ship dlls instead of depending on system versions of them?
Ideally we shouldn't do this, but i'm sure there are cases where its not possible to avoid. Maybe the mono auto-provides should only be looking in the public directories for dlls to auto-provide?
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. The alternatives system is an example. Multiple implementations should be allowed to co-exist on the system. Luckily mono seems to have a way to choose which DLL it wants to use (probably first in the GAC or whatever). The question is _"How should this be treated in package management?"_ (which is Fedora's concern).
I'm not sure these packages *actually* provide the things they say they do though. (Although I haven't looked at it.) I think they keep local per-app versions of some dlls in non-public directories. This means other apps will never pick up these dlls. However, the auto-provides finds them and marks the rpm.