[Mono-devel-list] Bride of GAC

[John Luke]

Mike Kestner wrote:

>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. ;-)
>
>  
>
I will apologize in advance for asking this, I should probably not send 
it and leave it up to those implementing it, but I hope it helps.

I read everything posted on this subject (GAC) I still don't get why 
fully qualified paths to the assemblies are needed.  People keep saying 
they need that, but I saw no explanation of why and what it 
accomplishes.  I can't help but think for whatever reason they do we 
could solve that differently.  If we don't really need that we can 
return to having the GAC resolve it for us like we had in cvs for a 
brief time that I liked and the rest of these things are unneeded, correct?

 I am not trying to stir things up, just understand why that assumption 
is needed.