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

[Jonathan Pryor]

The Linux solution to your scenario would be to place MySuperLib.dll
into it's own RPM, and NOT duplicate it across your other 3 packages. 
Each of your 3 packages would have the MySuperLib.dll RPM as a
dependency.

The benefit to this is that MySuperLib.dll won't be removed until all 3
packages are also removed.

The downside is that, if MySuperLib.dll is included in anyone else's
packages, and they're not using the same MySuperLib.dll RPM package as a
dependency, things break quickly.

They break quickly because RPM must know what files belong to what
package.  You cannot have the same file be present in > 1 package. 
Thus, if you either (a) don't use a MySuperLib.dll RPM package for your
own packages, or (b) someone bundles and attempts to install
MySuperLib.dll from their own RPM, you'll get file conflicts, and RPM
will refuse to install the new package.

This is, shall we say, undesirable, and provides further evidence that
directly placing the shared assembly into the GAC at RPM install time
(i.e. NOT using gacutil.exe) is not a good solution.

Along similar lines (thinking about the removal of packages),
gacutil.exe should probably place a copy of the assembly into the GAC,
and not use sym-links.  This way, if a package containing a
shared-assembly is removed, you won't have broken sym-links to worry
about, and the GAC will remain consistent.

 - Jon

On Fri, 2003-10-24 at 09:28, Todd Berman wrote:
> Just as a small RPM aside, out of curiosity, lets say that I have a shared
> assembly called 'MySuperLib.dll' that 3 packages I create use, and to make
> sure there are no unsatisfied dependencies, they all packaged it.
> 
> I go ahead and install all 3 directly into the gac, now, when I later remove
> one, is the lib I installed directly into the gac because it is part of the
> package list for that rpm? If so, packaging libraries this way is horribly
> broken. If not, then it seems like it might work.
> 
> And to address this question about the 'need' for the gacutil.exe, well, to
> me, we are attempting to create a workalike to .net. Now, .net has a
> gacutil.exe which they use to install assemblies into the gac, so that is
> part of the workalike.
> 
> In fact, .net has 2 main ways of installing something into the gac:
> 
> 1) gacutil.exe (not recommended, requires the .net framework sdk)
> 2) Windows Installer (recommended, no requirement on the .net framework, and
> if somehow the assembly gets removed, and an app needs it, if you have the
> .msi around it will get inserted automagically.)
> 
> Now, until inserting an assembly into the GAC becomes a first class member
> of the RPM/DEB/etc world, the gacutil.exe is really the only 'proper' way of
> doing it.
> 
> As I have said before, please understand that most libraries don't need to
> be in the GAC, and if, as a packager you want to use it out of conveniences
> sake, I would recommend actually creating a shell script to run the .exe
> (akin to the mcs script) that sets MONO_PATH to where you installed your
> packages private libraries.
> 
> --Todd
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list