Hi Toshio, Hi All,
On 01/20/2010 10:05 PM, Toshio Kuratomi wrote:
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:
It is quite hard for us to always fight against upstream. ;-) Even if
the way upstream would be not fully FHS compliant, it looks like that
they have created some kind of standard which is used by most mono
projects (and other distributions). So I think that it would be probably
better to adapt their standard in order to save lots of work. Since
Mono/Novell/OpenSuse are tightly coupled now, I assume that OpenSuse's
way of packaging mono is at least good aligned with upstream.
* If the files are architecture independent then they belong in
%{_datadir}
In general yes, but the FHS may be also read in that way that /usr/share
refers to data files and /usr/lib* refers to libraries and executables.
So putting arch independent byte code into /usr/lib seems to be OK
(according to FHS).
* If the files are architecture dependent, they belong in %{_libdir}
(which is
/usr/lib on x86 and /usr/lib64 of x86_64).
Hm, I tend to say to it OpenSuse's way is still correct according to the
FHS. It seems to be OK to put arch independent libraries into /usr/lib.
It looks like that e.g. perl in Fedora also puts libraries (arch
independent) into /usr/lib on x86_64 systems...
* Miguel has stated that the mono project reserves the right to make
the byte
code architecture dependent in the future.
Hm, but this collides with the other feedback we got for patches to fix
the lib64 issues the "Fedora-way" and the fact how OpenSuse handles
it... ;-)
* 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.
Not sure about this.
* 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.
As far as I understood it loading native libraries in mono works like
this: the bytecode just knows the name of the library, the name and
signature of the function it wants to call and once the function should
be executed, mono's runtime will dlopen the library and execute the
function if needed. I'm unsure whether in this case the assembly is
really arch dependent...
* 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.
Ok, And I've use OpenSuse as an example... ;-)
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
Yeah, agree. So that's why my suggestion is to use /usr/lib... ;-)
Best regards,
Christian