[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: mono Provides



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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]