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

[Jonathan Pryor]

On Wed, 2004-05-05 at 21:10, Todd Berman wrote:
<snip/>
> We still have a (imo) huge issue with regards to prefixes. I think this
> can be fixed by reversing the direction of our symlinks (instead of from
> $prefix/lib/mono/package/blah.dll to the real gac'd assembly, symlink
> the other way around). This will remove the need for some kind of hacky
> MONO_GAC_PATHS or something evil like that, as regardless of what prefix
> your libraries are really on, you would have them all symlink'd to the
> proper place. Of course, then you get into typical issue of touching
> files outside of the user requested prefix, and auto* distchecking, and
> that general unix nightmare.

The truly funny thing is that I (among others) had suggested a solution
similar to this back in October last year, in the "Potential GAC
implementation ideas" thread started by Todd Berman.

See:
http://lists.ximian.com/archives/public/mono-devel-list/2003-October/002672.html

Short version: The RPM packages don't place the shared assemblies
directly into the GAC.  Instead, they place them under:

	/usr/share/<project-name>

During RPM install, the post-install script would call gacutil /i, which
would install the assembly into the GAC.  gacutil /i would either create
a symlink from the GAC to the normal location, or create a direct copy;
it doesn't really matter.

At this point, we'd have two copies of the shared assemblies around: the
RPM-managed copy, and the GAC-managed copy.

The only problem is providing a simple mechanism for compilers to
determine the full path to an assembly.  pkg-config could be used here,
as Miguel has suggested.

 - Jon