[Mono-devel-list] GAC and third party libraries: post Beta planning.

[Todd Berman]

On Thu, 2004-06-05 at 16:11 +0200, Michal Moskal wrote:
> On Thu, May 06, 2004 at 09:27:47AM -0400, Todd Berman wrote:
> > On Thu, 2004-06-05 at 13:43 +0200, Michal Moskal wrote:
> > > On Wed, May 05, 2004 at 09:10:56PM -0400, Todd Berman wrote:
> > > > I dont see how the /probe replaces the need for /package.
> > > > 
> > > > You still have one of the issues that caused the need for /package in
> > > > the first place (Different versions of the same assembly). It seems that
> > > > it wouldn't replace it at all, but compliment it.
> > > 
> > > Oh, that's simple:
> > > 
> > > 	/usr/lib/pkgconfig/gtk+-2.0.pc
> > > 	/usr/lib/pkgconfig/gtk+.pc
> > > 
> > > The same way you can have gtk-sharp and gtk-sharp-2 or whatever.
> > 
> > Hah, not exactly.
> > 
> > The problem is where do the compiler reference-able assemblies go.
> > 
> > Right now it is determined by /package gtk-sharp which installs the
> > symlinks into $prefix/lib/mono/gtk-sharp/ and will eventually be used
> > with the -pkg: stuff.
> 
> I believe -pkg: will use no symlinks, but only pkg-config. And in
> gtk-sharp.pc will be: 
> 
>   libraries: /r:/usr/lib/mono/gac/gtk-sharp/1.0.0.0__35e10195dab3c99f/gtk-sharp.dll
> 
> No need for any symlink.
> 
> > The problem with removing that /package argument is where do the
> > gtk-sharp-2.0 assemblies go, the ones with the same filenames as the
> > gtk-sharp assemblies. Note, this is a compile time issue, *NOT* a
> > runtime issue as the gac solves this.
> 
> They have different version and go to GAC. And path in the GAC goes to
> gtk-sharp-2.pc. Plain and simple.

This was the original solution we had in mind with the gac, and was
roundly rejected by many of our windows based developers.

The problem with that is apparently the gac shouldnt be used to
reference assemblies at any time but runtime. It is designed to be an
opaque black box that just works. For right now it is file based, but
there are no promises in the future.

Having the symlinks (because our current setup allows it) in a seperate
place gives us something to migrate against if our gac setup changes
radically.

There are also other (believe it or not) uses for having a package
subdir like that.

I can think of a couple and list them here:

Someplace for monodoc to look for docs, to make doc bundling easier than
it is now.

Somewhere to store other tiny helper executables (so as to avoid
cluttering $prefix/bin with .exe'd files that arent exactly directly
executable (easily at least))

> 
> > This is why i said that I didnt see the /probe argument
> > replacing /package, but augmenting it.
> > > 
> > > > We still have a (imo) huge issue with regards to prefixes. 
> > > 
> > > Why should you care about prefixes? You just need to know how to call
> > > pkg-config -- and it should simply be in the PATH. Then you can simply
> > > do:
> > > 
> > > 	mcs -pkg:gtk-sharp foo.cs
> > > 
> > > and that's all.
> > 
> > Here you have the same confusion as above, but backward. Now the issue
> > is at runtime.
> > 
> > For example, lets say I have mono installed into /usr and i install
> > gtk-sharp into /usr/local.
> > 
> > the mono gac is /usr/lib/mono/gac/ and gtk-sharp gac's
> > into /usr/local/lib/mono/gac/. Thus gtk-sharp isnt found at runtime *or*
> > compile time, and everything is broken.
> 
> I see no good reason to have two GAC locations. Even when you install
> some other gtk-sharp files in /usr/local the dll's should IMHO go to
> /usr/lib/mono/gac.

what if the user installing doesnt have permissions to install
to /usr/lib

This is where we start to break out of the conventional unix packaging
mode and into territory where packagers get pissed.

As I said in my original followup, its easy to workaround, but the
question is if the workaround is something that we are willing to defend
(ie if you install mono from packages, and then want to install
gtk-sharp into a different prefix, you might still need to sudo to
install gtk-sharp because it writes into /usr)

--Todd