User:Chkr/MonoMultiarchChanges

From FedoraProject

< User:Chkr(Difference between revisions)
Jump to: navigation, search
m
m
Line 24: Line 24:
  
 
== Detailed Description ==
 
== Detailed Description ==
The way how mono is packaged in Fedora is uncommon with respect to mono's default search paths. In order to provide multi-arch support (32-bit and 64-bit run-time could be both installed on x86_64 systems), the standard mono's libdir /usr/lib was changed to %{_libdir}. 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.  
+
The way how mono is packaged in Fedora is uncommon with respect to mono's default search path. For various reasons the standard mono's libdir /usr/lib was changed to %{_libdir}. 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 (possibly with different content). 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.
 
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 (possibly with different content). 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.
  
Line 71: Line 71:
 
== Documentation ==
 
== Documentation ==
 
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
 
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
=== Existing issue ===
+
 
 +
=== Problem ===
 +
* mono-based packages may contain mono assemblies ("nearly arch-independent") and ELF binaries (e.g. glue code etc., arch-dependent)
 +
* 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 /usr/lib64 which causes the following issues
 +
** this is the source of many the packaging issues - most mono packages have this path hard-coded or even generate the path names at run-time
 +
** Fedora encourages the packagers to stay close to upstream and provide all changes as patches to upstream, however since in this case Fedora diverged 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
 +
** FHS specifies, that libraries should go to /usr/lib ( http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA )
 +
** Fedora is the only distribution which has made these changes
 +
*** OpenSUSE
 +
**** packages only containing mono bytecode are noarch
 +
**** GAC still in /usr/lib
 +
**** example: https://build.opensuse.org/package/binary?arch=x86_64&filename=gtk-sharp2-2.12.10-23.2.x86_64.rpm&package=gtk-sharp2&project=openSUSE%3A11.3&repository=standard
 +
 
 +
*** Debian
 +
**** custom location for the GAC in newer releases (but still in /usr/lib)
 +
**** example: http://packages.debian.org/sid/amd64/libgtk2.0-cil/filelist
 +
 
 +
 
 +
=== Examples for the necessary patches ===
 
* example from monodevelop.spec:
 
* example from monodevelop.spec:
 
<pre>
 
<pre>
Line 109: Line 132:
 
</pre>
 
</pre>
  
=== Idea ===
+
 
* mono-based packages may contain mono assemblies ("nearly arch-independent") and ELF binaries (e.g. glue code etc., arch-dependent)
+
* 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)
+
** Fedora moves the GAC into /usr/lib64
+
** this is the source of all the packaging pain - most mono packages have this path hard-coded
+
** move the GAC back to /usr/lib
+
** ability to install 32-bit mono runtime and 64-bit mono runtime gets lost (most likely no use case)
+
  
  

Revision as of 19:58, 8 May 2011


Contents

Mono Multiarch Changes

Summary

Remove the multiarch support for mono on x86-64 systems.

Owner

  • Email: chkr@fedoraproject.org

Current status

  • Targeted release: Fedora 16
  • Last updated: (DATE)
  • Percentage of completion: 00%


Detailed Description

The way how mono is packaged in Fedora is uncommon with respect to mono's default search path. For various reasons the standard mono's libdir /usr/lib was changed to %{_libdir}. 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 (possibly with different content). 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

  1. the Fedora-specific %{_libdir} patches have to be removed from all mono-based packages and they have to be re-compiled
  2. repoquery reports 114 packages which may be 50 separate source packages
  3. rel-eng must change the mash scripts to prevent that any mono-based packages are drawn into the x86_64 repository

How To Test

  1. install any mono-based package you like to use (preferably on x86 and on x86-64 systems)
  2. try whether it still works correctly

User Experience

  1. Most user won't recognize it.
  2. There may be some users who used the 32-bit mono core packages in x86-64. These packages will not be available anymore.

Dependencies

  • the "mash" tool to generate the x86-64 repositories must blacklist all -devel RPMS of the mono-based packages

Contingency Plan

  1. do the recompilation of all packages using a special build-target to check whether it works correctly
  2. in case it turns out that the migration can't be done, the git commits of the modified mono-based packages must be reverted
  3. since no builds where done for dist-rawhide, no rebuilds are necessary in that case

Documentation

Problem

  • mono-based packages may contain mono assemblies ("nearly arch-independent") and ELF binaries (e.g. glue code etc., arch-dependent)
  • 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 /usr/lib64 which causes the following issues


Examples for the necessary patches

  • example from monodevelop.spec:

sed -i -e 's!$(prefix)/lib/!%{_libdir}/!' \
    -e 's!${exec_prefix}/lib!%{_libdir}!' configure
sed -i -e 's!/lib/monodevelop!/%{_lib}/monodevelop!' monodevelop
sed -i -e 's!$PREFIX/lib/!%{_libdir}/!' mdtool.in
sed -i -e 's!monodevelop}/lib/!monodevelop}/%{_lib}/!' monodevelop.in

find . -name '*.cs' -and \
     ! \( -name 'GNUCompiler.cs' -or -name 'CProjectConfiguration.cs' \) \
      | while read f ;
        do
        sed -i -e 's!"lib"!"%{_lib}"!' "$f" 1>/dev/null
        done

find . -name Makefile.in -or -name \*.pc.in \
       -or -name \*.in -or -name \*.xml \
       | while read f ;
         do
           sed -i -e 's!$(prefix)/lib/!%{_libdir}/!' \
               -e 's!@prefix@/lib/!%{_libdir}/!' \
               -e 's!/usr/lib/!%{_libdir}/!' \
               -e 's!${exec_prefix}/lib/!%{_libdir}/!' "$f" 1>/dev/null
         done
  • another example from mono-basic.spec
%prep
%setup -q
sed -i -e 's!@libdir@!%{_libdir}!' %{PATCH0}
%patch0 -p1 -b .original
sed -i -e 's!%{_libdir}!@libdir@!' %{PATCH0}
sed -i -e 's!$(prefix)/lib/!%{_libdir}/!' build/config-default.make
sed -i -e 's!${exec_prefix}/lib!%{_libdir}!' configure



Necessary Changes

  • general rule: remove all patches in the mono-based packages which deals with altering the lib path
    • ensure, that mono assemblies are either
      • correctly installed into the gac in /usr/lib or
      • installed into %{_libdir}/progam (packages which contain ELF libraries) or
      • installed into /usr/lib/program (packages which contain only mono assemblies)
    • ensure, that ELF binaries are correctly installed into %{_libdir}
  • blacklist all mono packages from mash's "multi-arch" selection rule which pulls in 32bit packages into x86-64
  • these rules follow the same ideas as used by the python packages (in Fedora) and the mono packages in OpenSUSE
  • like OpenSUSE we may also change all mono packages which only contain mono binaries and no ELF binaries to noarch

Release Notes

  • no specific release notes necessary

Comments and Discussion