User:Chkr/MonoMultiarchChanges

From FedoraProject

< User:Chkr(Difference between revisions)
Jump to: navigation, search
m (Created page with '<!-- All fields on this form are required to be accepted by FESCo. We also request that you maintain the same order of sections so that all of the feature pages are uniform. --...')
 
m
 
(25 intermediate revisions by 2 users not shown)
Line 4: Line 4:
 
<!-- The actual name of your feature page should look something like: Features/YourFeatureName.  This keeps all features in the same namespace -->
 
<!-- The actual name of your feature page should look something like: Features/YourFeatureName.  This keeps all features in the same namespace -->
  
= Mono Multiarch Changes <!-- The name of your feature --> =
+
= Mono Default Paths / Multiarch Changes <!-- The name of your feature --> =
  
 
== Summary ==
 
== Summary ==
Remove the multiarch support for mono on x86-64 systems.
+
Change the default path for mono assemblies (and mono's global assembly cache) from %{_libdir} to /usr/lib. This will remove the multiarch support for mono on x86-64 systems.
  
 
== Owner ==
 
== Owner ==
Line 17: Line 17:
  
 
== Current status ==
 
== Current status ==
* Targeted release: [[Releases/14 | Fedora 14 ]]  
+
* Targeted release: [[Releases/17 | Fedora 17 ]]  
 
* Last updated: (DATE)
 
* Last updated: (DATE)
 
* Percentage of completion: 00%
 
* Percentage of completion: 00%
Line 24: Line 24:
  
 
== Detailed Description ==
 
== Detailed Description ==
The way how mono is packaged in Fedora with respect to support multiarch is uncommon with respect to mono's default search paths. 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. Solving this issue would include to 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 perl or python either.
+
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 ==
 
== Benefit to Fedora ==
 
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
 
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
This requires the maintainers to add lots of patches or "sed" constructs into the spec file in order to make all mono-based packages aware of this. All of these changes can't be upstreamed because they are contrary to the idea how mono should be located in the file system.
+
Much easier maintenance of all mono-based packages since all patches and hacks to change /usr/lib to %{_libdir} are not necessary anymore.
  
 
== Scope ==
 
== Scope ==
 
<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
 
<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
All mono-based packages most be re-compiled. <pre>repoquery --whatrequires mono(System)</pre> reports 114 packages which may be 50 separate source packages.
+
# the Fedora-specific %{_libdir} patches have to be removed from all mono-based packages and they have to be re-compiled
 +
# repoquery reports 114 packages which may be 50 separate source packages
 +
# rel-eng must change the mash scripts to prevent that any 32-bit mono-based packages are drawn into the x86_64 repository
  
 
== How To Test ==
 
== How To Test ==
Line 48: Line 53:
 
3. What are the expected results of those actions?
 
3. What are the expected results of those actions?
 
-->
 
-->
# install any mono-based package you like to use (preferably for x86 and x86-64)
+
# install any mono-based package you like to use (preferably on x86 and on x86-64 systems)
 
# try whether it still works correctly
 
# try whether it still works correctly
  
Line 54: Line 59:
 
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
 
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
 
# Most user won't recognize it.
 
# Most user won't recognize it.
# There may be some users who used the 32-bit mono core packagesin x86-64. These packages will not be available anymore.
+
# It may solve some unreported issues caused by the change default paths.
 +
# There may be some users who used the 32-bit mono core packages in x86-64. These packages will not be available anymore.
  
 
== Dependencies ==
 
== Dependencies ==
Line 63: Line 69:
 
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
 
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
 
# do the recompilation of all packages using a special build-target to check whether it works correctly
 
# do the recompilation of all packages using a special build-target to check whether it works correctly
# don't remove the patches for the packages from the CVS yet
+
# in case it turns out that the migration can't be done, the git commits of the modified mono-based packages must be reverted
# in case it turns out that the migration can't be done, the spec files of the modified mono-based packages must be reverted
+
# since no builds were done for dist-rawhide, no rebuilds are necessary in that case
# since no builds where done for dist-rawhide, no rebuilds are necessary
+
  
 
== 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 ===
+
 
 +
=== Rationale ===
 +
* mono-based packages may contain mono assemblies (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 %{_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
 +
 
 +
There are two main questions:
 +
 
 +
* '''Are mono assemblies (*.dll, *.exe) architecture independent?'''
 +
* Fedora previously assumed, that they are not (based on http://lists.alioth.debian.org/pipermail/pkg-mono-devel/2005-February/000370.html )
 +
** 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
 +
*** details: http://lists.ximian.com/pipermail/mono-devel-list/2011-May/037591.html , http://lists.ximian.com/pipermail/mono-devel-list/2011-May/037593.html
 +
*** AOT compilations would be architecture-dependent, but they are not in use right now
 +
 
 +
* '''Given that mono assemblies are platform independent, should they go into %{_datadir} or /usr/lib ?'''
 +
** FHS specifies, that libraries should go to /usr/lib ( http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA )
 +
** 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)
 +
 
 +
* What does other distributions do:
 +
** 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 currently necessary patches ===
 
* example from monodevelop.spec:
 
* example from monodevelop.spec:
 
<pre>
 
<pre>
Line 106: Line 151:
 
sed -i -e 's!${exec_prefix}/lib!%{_libdir}!' configure
 
sed -i -e 's!${exec_prefix}/lib!%{_libdir}!' configure
 
</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)
 
  
  
 
=== Necessary Changes ===
 
=== Necessary Changes ===
* general rule: remove all patches in the mono-based packages which deals with altering the lib path
+
* general rule: remove all patches and "sed" calls in the spec file of the mono-based packages which deals with altering the lib path
** ensure, that mono assemblies are either
+
** ensure, that mono assemblies (for both i686 and x86_64 packages!) are either
*** correctly installed into the gac in /usr/lib or
+
*** correctly installed into the gac in /usr/lib/mono or
*** installed into %{_libdir}/progam (packages which contain ELF libraries) or
+
*** installed into /usr/lib/$monoprogram
*** installed into /usr/lib/program (packages which contain only mono assemblies)
+
 
** ensure, that ELF binaries are correctly installed into %{_libdir}
 
** 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
 
* 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
 
* 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
 +
* packages which contain mono assemblies and ELF libraries should not be splitted but they will remain arch-dependent:
 +
** does not solve any real issues
 +
** unnecessary work
 +
** not done for perl and python either
 +
 +
* detailed step-by-step
 +
*# announce changes on fedora-mono mailing list
 +
*# ask rel-eng for a special koji-target: "f17-mono" to update the 64 packages without interfering with rawhide
 +
*# fix/verify mono core packages: mono, libgdiplus, mono-tools, boo, nant, mono-addins, gtk-sharp in rawhide
 +
*# fix all remaining mono-based packages:
 +
<pre>
 +
avahi-0:0.6.30-4.fc17.src
 +
banshee-0:2.0.1-2.fc16.src
 +
banshee-community-extensions-0:2.0.1-2.fc16.src
 +
bareftp-0:0.3.9-1.fc17.src
 +
blam-0:1.8.7-3.fc14.src
 +
bless-0:0.6.0-7.fc16.src
 +
boo-0:0.9.4.9-2.fc16.src
 +
cdcollect-0:0.6.0-12.fc15.src
 +
chronojump-0:0.8.14-1.fc12.src
 +
clutter-sharp-0:0-0.14.20090828.fc17.src
 +
dbus-sharp-0:0.63-17.fc15.src
 +
docky-0:2.0.12-1.fc17.src
 +
f-spot-0:0.8.2-3.fc16.src
 +
flickrnet-0:2.2-8.fc15.src
 +
gdata-sharp-0:1.4.0.2-5.fc15.src
 +
gecko-sharp2-0:0.13-20.fc16.src
 +
gio-sharp-0:0.3-2.fc16.src
 +
gkeyfile-sharp-0:0.1-7.fc16.src
 +
gmime-0:2.5.8-1.fc16.src
 +
gnome-desktop-sharp-0:2.26.0-13.fc15.src
 +
gnome-do-0:0.8.5-7.fc17.src
 +
gnome-do-docklets-0:0.8.2-4.fc15.src
 +
gnome-do-plugins-0:0.8.4-2.fc16.src
 +
gnome-guitar-0:0.8.1-10.fc16.src
 +
gnome-keyring-sharp-0:1.0.1-0.8.133722svn.fc15.src
 +
gnome-rdp-0:0.2.3-9.fc16.src
 +
gnome-sharp-0:2.24.1-6.fc16.src
 +
gnome-subtitles-0:1.2-1.fc17.src
 +
gsf-sharp-0:0.8.1-15.fc15.src
 +
gtk-sharp2-0:2.12.11-1.fc17.src
 +
gtksourceview-sharp-0:2.0.12-14.fc16.src
 +
gtksourceview2-sharp-0:1.0-10.svn89788.fc16.src
 +
ice-0:3.4.2-3.fc17.src
 +
libgpod-0:0.8.2-1.fc16.src
 +
log4net-0:1.2.10-16.fc16.src
 +
mod_mono-0:2.10-1.fc16.src
 +
mono-addins-0:0.6.2-2.fc17.src
 +
mono-basic-0:2.10-2.fc17.src
 +
mono-bouncycastle-0:1.7-1.fc16.src
 +
mono-cecil-flowanalysis-0:0.1-0.15.20110512svn100264.fc16.src
 +
mono-debugger-0:2.10-1.fc16.src
 +
mono-nat-0:1.1.0-1.fc16.src
 +
mono-reflection-0:0.1-0.2.20110613git304d1d.fc16.src
 +
mono-tools-0:2.10-3.fc16.src
 +
mono-zeroconf-0:0.9.0-5.fc15.src
 +
monodevelop-0:2.6-2.fc17.src
 +
monodevelop-debugger-gdb-0:2.6-1.fc17.src
 +
monodevelop-vala-0:2.6-1.fc17.src
 +
monsoon-0:0.21-4.fc13.src
 +
nant-1:0.90-6.fc16.src
 +
ndesk-dbus-0:0.6.1b-1.fc13.src
 +
ndesk-dbus-glib-0:0.4.1-10.fc15.src
 +
notify-sharp-0:0.4.0-0.14.20100411svn.fc15.src
 +
pinta-0:1.0-1.fc16.src
 +
taglib-sharp-0:2.0.3.7-3.fc16.src
 +
taoframework-0:2.1.0-3.fc17.src
 +
themonospot-base-0:0.8.2-7.fc16.src
 +
themonospot-console-0:0.1.1-6.fc16.src
 +
themonospot-gui-gtk-0:0.2.2-7.fc16.src
 +
themonospot-gui-qt-0:0.1.3-10.fc16.src
 +
themonospot-plugin-avi-0:0.1.1-6.fc16.src
 +
themonospot-plugin-mkv-0:0.1.1-6.fc16.src
 +
webkit-sharp-0:0.3-6.fc16.src
 +
xsp-0:2.10.2-1.fc16.src
 +
</pre>
 +
#* if everything works as expected, ask rel-eng to block the mono-devel packages from mash'ing into multi-arch x86_64
  
 
== Release Notes ==
 
== Release Notes ==
 
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
 
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
 
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
 
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
* no necessary
+
* no specific release notes necessary
  
 
== Comments and Discussion ==
 
== Comments and Discussion ==

Latest revision as of 14:41, 15 October 2011


Contents

[edit] Mono Default Paths / Multiarch Changes

[edit] Summary

Change the default path for mono assemblies (and mono's global assembly cache) from %{_libdir} to /usr/lib. This will remove the multiarch support for mono on x86-64 systems.

[edit] Owner

  • Email: chkr@fedoraproject.org

[edit] Current status

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


[edit] 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.

[edit] 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.

[edit] 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 32-bit mono-based packages are drawn into the x86_64 repository

[edit] 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

[edit] User Experience

  1. Most user won't recognize it.
  2. It may solve some unreported issues caused by the change default paths.
  3. There may be some users who used the 32-bit mono core packages in x86-64. These packages will not be available anymore.

[edit] Dependencies

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

[edit] 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 were done for dist-rawhide, no rebuilds are necessary in that case

[edit] Documentation

[edit] Rationale

  • mono-based packages may contain mono assemblies (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 %{_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

There are two main questions:

  • Given that mono assemblies are platform independent, should they go into %{_datadir} or /usr/lib ?
    • FHS specifies, that libraries should go to /usr/lib ( http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA )
    • 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)


[edit] Examples for the currently 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


[edit] Necessary Changes

  • general rule: remove all patches and "sed" calls in the spec file of the mono-based packages which deals with altering the lib path
    • ensure, that mono assemblies (for both i686 and x86_64 packages!) are either
      • correctly installed into the gac in /usr/lib/mono or
      • installed into /usr/lib/$monoprogram
    • 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
  • packages which contain mono assemblies and ELF libraries should not be splitted but they will remain arch-dependent:
    • does not solve any real issues
    • unnecessary work
    • not done for perl and python either
  • detailed step-by-step
    1. announce changes on fedora-mono mailing list
    2. ask rel-eng for a special koji-target: "f17-mono" to update the 64 packages without interfering with rawhide
    3. fix/verify mono core packages: mono, libgdiplus, mono-tools, boo, nant, mono-addins, gtk-sharp in rawhide
    4. fix all remaining mono-based packages:
avahi-0:0.6.30-4.fc17.src
banshee-0:2.0.1-2.fc16.src
banshee-community-extensions-0:2.0.1-2.fc16.src
bareftp-0:0.3.9-1.fc17.src
blam-0:1.8.7-3.fc14.src
bless-0:0.6.0-7.fc16.src
boo-0:0.9.4.9-2.fc16.src
cdcollect-0:0.6.0-12.fc15.src
chronojump-0:0.8.14-1.fc12.src
clutter-sharp-0:0-0.14.20090828.fc17.src
dbus-sharp-0:0.63-17.fc15.src
docky-0:2.0.12-1.fc17.src
f-spot-0:0.8.2-3.fc16.src
flickrnet-0:2.2-8.fc15.src
gdata-sharp-0:1.4.0.2-5.fc15.src
gecko-sharp2-0:0.13-20.fc16.src
gio-sharp-0:0.3-2.fc16.src
gkeyfile-sharp-0:0.1-7.fc16.src
gmime-0:2.5.8-1.fc16.src
gnome-desktop-sharp-0:2.26.0-13.fc15.src
gnome-do-0:0.8.5-7.fc17.src
gnome-do-docklets-0:0.8.2-4.fc15.src
gnome-do-plugins-0:0.8.4-2.fc16.src
gnome-guitar-0:0.8.1-10.fc16.src
gnome-keyring-sharp-0:1.0.1-0.8.133722svn.fc15.src
gnome-rdp-0:0.2.3-9.fc16.src
gnome-sharp-0:2.24.1-6.fc16.src
gnome-subtitles-0:1.2-1.fc17.src
gsf-sharp-0:0.8.1-15.fc15.src
gtk-sharp2-0:2.12.11-1.fc17.src
gtksourceview-sharp-0:2.0.12-14.fc16.src
gtksourceview2-sharp-0:1.0-10.svn89788.fc16.src
ice-0:3.4.2-3.fc17.src
libgpod-0:0.8.2-1.fc16.src
log4net-0:1.2.10-16.fc16.src
mod_mono-0:2.10-1.fc16.src
mono-addins-0:0.6.2-2.fc17.src
mono-basic-0:2.10-2.fc17.src
mono-bouncycastle-0:1.7-1.fc16.src
mono-cecil-flowanalysis-0:0.1-0.15.20110512svn100264.fc16.src
mono-debugger-0:2.10-1.fc16.src
mono-nat-0:1.1.0-1.fc16.src
mono-reflection-0:0.1-0.2.20110613git304d1d.fc16.src
mono-tools-0:2.10-3.fc16.src
mono-zeroconf-0:0.9.0-5.fc15.src
monodevelop-0:2.6-2.fc17.src
monodevelop-debugger-gdb-0:2.6-1.fc17.src
monodevelop-vala-0:2.6-1.fc17.src
monsoon-0:0.21-4.fc13.src
nant-1:0.90-6.fc16.src
ndesk-dbus-0:0.6.1b-1.fc13.src
ndesk-dbus-glib-0:0.4.1-10.fc15.src
notify-sharp-0:0.4.0-0.14.20100411svn.fc15.src
pinta-0:1.0-1.fc16.src
taglib-sharp-0:2.0.3.7-3.fc16.src
taoframework-0:2.1.0-3.fc17.src
themonospot-base-0:0.8.2-7.fc16.src
themonospot-console-0:0.1.1-6.fc16.src
themonospot-gui-gtk-0:0.2.2-7.fc16.src
themonospot-gui-qt-0:0.1.3-10.fc16.src
themonospot-plugin-avi-0:0.1.1-6.fc16.src
themonospot-plugin-mkv-0:0.1.1-6.fc16.src
webkit-sharp-0:0.3-6.fc16.src
xsp-0:2.10.2-1.fc16.src
    • if everything works as expected, ask rel-eng to block the mono-devel packages from mash'ing into multi-arch x86_64

[edit] Release Notes

  • no specific release notes necessary

[edit] Comments and Discussion