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

[Michal Moskal]

On Thu, Oct 23, 2003 at 06:03:10PM -0400, Joe Shaw wrote:
> On Thu, 2003-10-23 at 17:55, Todd Berman wrote:
> > > That would be the packager's responsibility, as it is with shared
> > > libraries on Linux today.
> > 
> > That's the point of the GAC, it isn't the packagers concern anymore.
> > 
> > The packager should be concerned with getting the library to the GAC (if it
> > even needs to be, a library shouldn't be in the GAC unless two separate
> > packages need it), not worrying about how to gets there, where it actually
> > goes, or anything else.
> 
> That sort of breaks the model with packaging on Linux, though.  In the
> RPM, there's a reference to a file, and that file has to go *somewhere*,
> so why not put it where it's supposed to go? :)
> 
> The tool to tell it where to go could be done at build-time, rather than
> installation-time, unless there's some reason why the file would go to
> different locations on different machines (different $prefix
> notwithstanding)

Something like:

%install
...
# this should be done by Makefile probably
gacutil --DESTDIR $RPM_BUILD_ROOT --install foo.dll
gacutil --DESTDIR $RPM_BUILD_ROOT --install bar.dll
...
# this would just output list of all DLLs with full names
# assuming / is in $RPM_BUILD_ROOT
gacutil --find-files $RPM_BUILD_ROOT > gac.list

%post
# recreate any internal GAC caches
gacutil --cache

%postun
# also after removal
gacutil --cache

# and this would include proper files in RPM
%files -f gac.list
%{_bindir}/foo.exe
%{_datadir}/foo.png

This would be nice.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith : GCS {C,UL}++++$ a? !tv
: When in doubt, use brute force. -- Ken Thompson : {E-,w}-- {b++,e}>+++ h