On Wed, Jan 20, 2010 at 09:43:07PM +0100, Christian Krause wrote:
The way Fedora has chosen to support x86-64 systems is not accepted
upstream (e.g. see
https://bugzilla.novell.com/show_bug.cgi?id=553642).
This causes a lots of trouble for us packagers with lots of patches for
x86-64 support.
The main reason is, that Fedora puts mono bytecode (*.exe, *.dll) into
/usr/lib{,64} although most projects expect them in /usr/lib since the
byte code should not be architecture dependent. It looks like that
others like opensuse puts only architecture specific ELF binaries into
/usr/lib64 and all mono bytecode goes into /usr/lib.
I'll send around a more detailed mail about this issue in the next days.
However, if we decide to fix this in Fedora, there will be enough work
for us for rawhide.
So we've had this discussion before. It boils down to:
* If the files are architecture independent then they belong in %{_datadir}
* If the files are architecture dependent, they belong in %{_libdir} (which is
/usr/lib on x86 and /usr/lib64 of x86_64).
* Miguel has stated that the mono project reserves the right to make the byte
code architecture dependent in the future.
* AOT compiled mono assemblies are architecture dependent and the current
mono interpreter can only load them when they are in the same directory
as the assemblies.
* Mono assemblies can be architecture dependent when they load native
libraries. No one has given a way to detect when this is a problem at
review time and do the right thing.
* Debian puts the assemblies into their architecture dependent directory --
since Debian does not do multilib, that directory is /usr/lib. Otherwise
they would install into /usr/share.
So, these are the problems that need to be addressed in order to shift where
mono is installed... note that such a shift probably won't solve anything as
you'd be moving from /usr/lib64 to /usr/share
-Toshio