myfedora at richip.dhs.org
Thu Sep 20 12:57:40 UTC 2007
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).
Perhaps the user should be given the option to choose which
implementation or package to install? Maybe priorities can be assigned
to packages whose sole purpose is to actually provide that interface
implementation (as opposed to packages which happen to just use them).
Let's take JVM's, for instance. I can have several packages which
actually provide JVM implementations, and I can also have Java apps that
might want to package a JVM along with the app. Unlike mono, the choice
of which JVM or JAR file to use depends on the alternatives system or
might be overridden by the application.
Or take Firefox. Maybe a firefox package out there could come with it's
own xulrunner implementation (which it currently does) or it could come
without it and require one to already be on the system.
On a slight tangent: I wonder how effective the alternatives system
really is and if mono might not be coerced to use it. It's interesting
from a systems administration POV to either centralize control at some
level (be it low-level like that or abstracted at a GUI level).
My thoughts are just rambling now.
More information about the fedora-devel-list