[Mono-devel-list] Re: Potential GAC implementation ideas.

[Todd Berman]

> On Thu, Oct 23, 2003 at 06:33:32PM -0400, Todd Berman wrote:
> > Now, the more recent and long part of this thread is about how a
> packager
> > can get his assembly to the gac.
> 
> For package managers:
> 
> a) gacutil should provide mode in which it will install just DLLs (not
>    run ngen), and won't install it in / but in specified directory. This
>    is best set with environment variable, GACUTIL_DESTDIR or something
>    like this.

Gacutil will not ngen assemblies ever. A tool called ngen.exe or similar
will do this.
 
> b) and second mode in which it will traverse it's directories and look
>    for assemblies that are not ngened and ngen them

Gacutil will not ever do this, ngen does this

> c) third mode in which it will look for ngened assemblies that have no
>    corresponding DLL anymore.

Again, different tool.

> ngened images are stored somewhere in /var/lib/monogac and rpm doesn't
> touch them.
> 
> This way rpm spec could look like this (I assume very similar setting
> for debs):
> 
> %install
> # project Makefile has usual "gacutil /i foo.dll" call, but
> $GACUTIL_DESTDIR
> # tells it not to run ngen and to use
> # $GACUTIL_DESTDIR/usr/share/monogac/$version/$name/whatever and not
> # /usr/share/monogac/$version/$name/whatever.
> 
> GACUTIL_DESTDIR=$RPM_BUILD_ROOT make install
> 
> %post
> gacutil --ngen
> 
> %postun
> gacutil --clean-ngen
> 
> %files
> /usr/share/monogac/*
> 
> 
> Different setting could be that pre-ngened binaries come with RPMS, this
> would be harder to support I suppouse.

RPMs should never ship with ngen'd binaries as they are OS, arch, and
runtime specific, that's just a asking for disaster :P


So, basically what you are saying, is you want whatever code that goes to
implement the GAC respect the fakeroot that you use to build the RPM? If so
I wouldn't worry to much, as something like that will surely exist for
making RPMs of mono itself.

Now, I still wouldn't endorse the use of it, it could have potential issues
down the road if the GAC format changes.

As well, you need to evaluate what the GAC is for, its not a place to store
ALL your assemblies, just a place to store versioned shared assemblies.

--Todd