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

[Mike Kestner]

On Thu, 2004-05-06 at 06:23, Jonathan Pryor wrote:

> 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

We discussed this approach on a conference call at one point over the
weekend, but it's all a blur to me now as to why we didn't go that way.

I personally like this approach.  Not only does it solve the
distribution problem, I think it solves several problems gracefully on
UNIX.  Here's how I see it in action for Gtk#:

The pc files can be generated at configure time because they don't
depend on gacutil to probe the *built* assembly for an install path. 
Instead, you just path to prefix/share/package for each assembly on your
libs variable.  All building happens through a prefix that can be
completely independent of the mono installation prefix.

On make install, we install all the dlls, dll.configs, and pc files to
the prefix and run gacutil /user /i  to install the dlls to the user gac
for testing.  The remaining challenge here is how to deal with people
who want to build from source instead of using packages, but install to
the system gac.  

We could probably deal with this via MAINTAINER_MODE so that when
building from cvs we use gacutil /user, but with tarballs we install to
the system gac.  Todd's idea of having a fallback for gacutil that
checks if privs are available for the system gac install and if not,
uses the user gac, would work for people who want to install from source
without root privs.

Also, what happens if both the user gac and the system gac have
gtk-sharp dll version 1.0.0.0?  If the system gac is preferred, then we
can work around the problem by bumping the assembly version for bugfix
testing, which we should probably be doing anyway once we've released
1.0.

-- 
Mike Kestner <mkestner at ximian.com>