[Mono-devel-list] Bride of GAC

[Todd Berman]

This is all good, and I love of all of it, but what about regular system
libraries (currently symlinked in $prefix/lib/mono/1.0/)?

I think there are a lot of seperate issues here getting somewhat
confused.

1) How will mcs reference system libraries (anything thats part of the
mono-* packages).
2) How will third party libraries install and be located in the gac by
mono at runtime.
3) How will mcs find these third party libraries.

Right now mcs references the system libraries because Assembly.Load
searches the AppBase for assembly matches, and mcs.exe is in
$prefix/lib/mono/1.0/. I dont know if there is really anyway to remove
this, as the previous LoadAssemblyFromGac code was really a bad hack
that would not have handled well with 1.1 and 2.0 assemblies in the gac.

As far as installing third party libraries (like gtk-sharp, gecko-sharp,
etc) I would think that miguel's solution of having gacutil output
fullpaths that are completely /r:-able and stuffed into a .pc file seems
to make sense.

However, as Mike notes, it adds a *huge* amount of crap to be handled by
a library provider. To me, this is no more or less elegant than the
symlink + sane pkg-config solution.

I am mainly just unsure exactly what is the issue with the current
solution (outside of requiring the kinda ugly shell script fix to
prevent breaking existing samples, which will be broken with this new
solution regardless).

--Todd

On Tue, 2004-11-05 at 15:53 -0500, 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. ;-)
> 
> -- 
> Mike Kestner <mkestner at ximian.com>
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list