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

[Mike Kestner]

On Wed, 2004-05-12 at 10:07, Miguel de Icaza wrote:
> > I'm afraid I distracted from that issue by raising some of the more
> > nuisance related issues like configure expansion of pc.in files. This
> > does address some of those, and shortens each assembly path by at least
> > a version# and key value in the pkg-config expansion.
> 
> So can you sum up what is the major issue you are facing?

Scenario 1:

cd mono && configure --prefix=foo && make && make install
cd gtk-sharp && configure --prefix=bar && make && make install

This leaves me without a prefixed installation, because all my
assemblies go into foo, not bar.  Prefixed installations are handy for
development and bugfixing, and under the current GAC implementation my
only real alternative for multiple gtk-sharp prefixes is to maintain a
separate mono prefix for each "interesting" configuration. 

This is what I'm currently doing with Gtk# since beta1 shipped.  I
installed an /opt/mono version from the mono-0.91 tarball so that I
don't have to install my development versions of gtk-sharp into /usr
with admin priviledges. Obviously, this gets more fun the higher you
climb the 3rd party dependency stack.

Scenario 2:

- User is unprivileged cluster user
- Cluster has admin installed mono
- User wants to try app X which uses a GAC-ified library "foo"
- User attempts to install foo and fails because they have no privs for
mono prefix.

Scenario 3:

- same as 2, except user has write privs to a group shared prefix (but
not the admin-maintained mono prefix) and is going to maintain a Gtk#
bleeding edge version for a development team.  This is the scenario that
kills the user gac, because a fallback install to the user gac by user1
doesn't help group members user2 .. userN.

There are other variations on the theme.  The common thread is a lack of
an LD_LIBRARY_PATH equivalent for GAC installed libraries.

-- 
Mike Kestner <mkestner at ximian.com>