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

Joe Shaw joe at ximian.com
Thu Oct 23 17:20:15 EDT 2003

On Thu, 2003-10-23 at 17:04, Todd Berman wrote:
> Well, I'm pretty sure that they wouldn't fail, especially if the force flag
> is used.
> What about uninstalling the rpm though, is there a way to script that?

There are pre- and post-scripts for both installation and removal inside
of RPM.  The problem with the post-install script, however, is that the
files are changed on the filesystem by the time the scripts are run, so
if the script fails, the entire transaction isn't rolled back.  This
means a potential inconsistent state if that script fails.  Using the
force flag to RPM doesn't have any effect on that, and in fact almost
always makes things worse.

The disadvantage to requiring a program to register assemblies is that
if that utility fails, the RPM is still installed but the DLL isn't
registered.  You'd have to go through and manually run the registration
program on every DLL in between when you installed them (ie, when the
GAC was broken) and when you fixed them.  This is particularly annoying
when you don't know how or why the registration program failed.  If
you're using command-line rpm, you'll probably get the error messages on
standard error and you'll see them, but if you're using an automated or
graphical tool like anaconda or red-carpet, they're probably stuck in
some log file somewhere.

The advantage to just having mono pick them up automatically (a
conf.d-like setup) is that there's no intervention required; once you've
fixed the GAC they Just Work.  But the disadvantage then is that the
layout and implementation of the GAC become public and basically a part
of the mono ABI.

You could have a pre-uninstall script to remove them from the GAC, but
that too has issues, especially if you can't differentiate between
certain errors (ie, "DLL wasn't registered" or "file not found" probably
shouldn't be fatal, but some other more serious "cannot remove from GAC"
might be).


More information about the Mono-devel-list mailing list