[Mono-devel-list] Bride of GAC

[Mike Kestner]

In the interest of trying to drive the GAC installation discussion
forward, the following are my thoughts on the current proposal from
Miguel.

We are in complete agreement that a -pkg switch to mcs would be a good
thing for development on *nix platforms.

Miguel also wants to eliminate the use of symlinks and does not want to
replace symlinks with assembly copying.  I agree that both are good
objectives. Unfortunately, I can't come up with any "beautiful"
approaches to prefixed installation that don't include symlinks or
copying, given our filesystem-based GAC implementation.

Miguel's proposal is to install assemblies to the gac, and add a switch
to gacutil to obtain the path that an assembly will be installed to so
that we can put fully qual'd paths to assemblies in the /r: references
in our .pc files.

This approach makes it basically impossible to install without
privileges for the mono directory with our current GAC implementation.
Even if we add a fallback to the user gac for failed gacutil /i
attempts, doing the fallback could result in a broken install, since an
install to a group shared prefix wouldn't produce a shared installation
due to the user gac not being "shared".

So basically, taking this approach, we are forcing installation into the
mono prefix with permissions for that prefix.  For Gtk#, the only things
which would actually be installed to the prefix under a prefixed build
would be the .pc files, glue, and the gapi binaries/scripts.

To produce .pc files with a fully-qual'd path to the assemblies, we'll
have to delay the pc file creation until "make" time by adding rules
which depend on the assembly, since gacutil will need a built assembly
in order to tell us where it will be installed.  I've typically liked
being able to build my pc files at configure time, but Miguel tells me
there's a reason I probably shouldn't be doing this anyway.  The result
is additional rules needing to be written to produce something that Just
Worked (TM) before with config substitutions from my perspective.  I
don't see any other way to do this though, if we have to have
one-and-only-one-file-reference representing an assembly.

So, my least of all evils proposal given the constraints above is to
enhance Miguel's proposal with the addition of a MONO_GAC_PATH
environment variable.  MONO_GAC_PATH would be searched *after* the
system GAC in the interest of protecting against malicious or accidental
"replacements" of a system assembly as a user.  MONO_GAC_PATH would
allow for true prefixed installation, where all files, assemblies
included, are installed to the specified prefix.  This would facilitate
multiple-prefixed installations and installation with user priviledges.

For development purposes it's sometimes nice/necessary to be able to
just rm -r $(prefix)/* to be able to start over with a development
version of a package.  Currently, removing a gtk-sharp install would
involve a lot of painstaking work picking through the system GAC.

Yes I know that an ENV variable solution could never be called
"beautiful", but we have lots of precedents around, including
LD_LIBRARY_PATH which is clearly relevant in this context.  It's
obviously good enough for ld.

Now everyone can point out to me why it would suck for the GAC. ;-)

-- 
Mike Kestner <mkestner at ximian.com>