[Fedora-packaging] Mono Packaging Issues

Tom 'spot' Callaway tcallawa at redhat.com
Mon Jun 12 23:23:32 UTC 2006

As I look into lifting the hold on Mono packages in Fedora Extras (aka,
blessing the mono packaging guidelines found here:
http://fedoraproject.org/wiki/Packaging/Mono), I'd like to state my
opinions on the following blocker issues:

1. Redefining libdir for mono packages:

If mono and its tools cannot find a library on a 64bit architecture when
it lives in %{_libdir} (/usr/lib64), then mono is fundamentally broken
on that architecture, and needs to be fixed. This is a serious flaw, and
I will not have us doing ugly hacks in spec files to work around mono's
ineptitude. Every other core component is able to handle this, this bug
should be filed and fixed.

2. Putting DLLs in %{_datadir} vs %{_libdir}:

The FHS says that /usr/share (aka, %{_datadir}) is for "Architecture
Independent Data". These DLL files do not seem to qualify as
"Architecture Independent Data". I think that having them live in the:
%{_libdir}/mono/ hierarchy seems to be the most appropriate for them at
this point in time. Obviously, this can be revisited if upstream changes
the default location. The gacutil command should be putting these DLL
files in the right place.

3. Forcing local copies of DLL libraries instead of using system
installed DLLs.
This concept is documented upstream here:
IMHO, this is a really stupid and braindead idea. In fact, I've yet to
talk to anyone who actually thinks this is a good idea. This is the same
thing as static linking a private copy of a library instead of using the
system shared lib. We do NOT permit this sort of behavior in Fedora, and
mono is no exception.

I've copied alexl on this email, since he is the mono owner in Fedora
Core, and likely has an opinion or two. ;)

Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

More information about the Fedora-packaging mailing list