Owner

Current status

Detailed Description

The way how mono is packaged in Fedora is uncommon with respect to mono's default search path. For various reasons the default path for mono assembles and the mono "Global Assembly Cache" ( /usr/lib and /usr/lib/mono) was changed to %{_libdir} in Fedora. This causes lots of unnecessary work by the maintainers and quite a couple of bug reports due to uncaught uses of these default paths within the mono packages.
Reverting this decision and using again mono's standard search path /usr/lib would result in conflicts between i686 and x86_64 packages because both would contain the same files. Although the assemblies are the same, the files may differ due to strings referring to the build architecture).

That means, that we would have to prevent that any mono i686 package would be drawn into the x86_64 repos and so we would loose the ability to use 32bit parts of the mono stack in x86-64 - a feature which never worked correctly and is not available for other run-time environments like perl or python either.

Benefit to Fedora

Much easier maintenance of all mono-based packages since all patches and hacks to change /usr/lib to %{_libdir} are not necessary anymore.

Scope

the Fedora-specific %{_libdir} patches have to be removed from all mono-based packages and they have to be re-compiled

Documentation

Rationale

the assemblies are usually put in the GAC, mono's "global assembly cache"

the arch-dependent files are correctly copied into %{_libdir}

upstream places the gac into /usr/lib (/usr/lib/mono/gac) (regardless of the actual architecture)

Fedora moves the GAC into %{_libdir} (which is /usr/lib64 on x86_64) which causes the following issues

packaging problems - most mono packages have this path hard-coded or even generate the path names at run-time, so all mono packages must be patched

Fedora encourages the packagers to stay close to upstream and provide all changes as patches to upstream, however since in this case Fedora diverges from upstream (and all other distributions), none of the necessary patches and fixes for changing /usr/lib to /usr/lib64 can be upstreamed

Upstream does not care about any issues Fedora has regarding any problems which result of using %{_libdir}

Fixing all of the issues is a tedious and self-defeating work which actually does not solve any real-world problems but is only necessary because of Fedora's "self-made" problem

I have verified with mono upstream, that this is not their position anymore:

mono assemblies are in general architecture independent, every CLI runtime-environment should be able to execute them

in theory it is possible to write architecture-dependent native bindings, but doing so is discouraged and is treated (even by upstream) as a bug which should be fixed

if it is hard to generate a binding because of platform dependencies in the native library, the developers are encouraged to write gluecode libraries (native) which provide an interface which C# code can utilize with platform independent code

FHS specifies further: "The /usr/share hierarchy is for all read-only architecture independent data files [...] Much of this data originally lived in /usr (man, doc) or /usr/lib (dict, terminfo, zoneinfo)."

FHS does not forbid to place arch-independent files into /usr/lib. It only forbids to place arch-dependent files into /usr/share

Placing the mono assemblies into /usr/share would not solve the mentioned issue (see above)

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, and JBoss are trademarks or registered trademarks of
Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community
maintained site. Red Hat is not responsible for content.