Hi,
Mono (and mono-packages) are currently packaged to %{_libdir} as per the published guidelines for packaging.
There has been discussion, both recently and in the past, about moving mono to .noarch packages and placing them in /usr/share. The rational behind this is that .NET CIL is a non-architecture specific system which calls on a central repository of dlls held within GAC. It is a shared resource rather than a platform specific resource. It is also not a traditional library (.so).
While there is no arguing that .so (and standard linux library files) should remain in %{_libdir}, non-native libs should not live there; it pollutes and causes problems elsewhere. Simple example, if you live on a 64 bit box and install a prebuilt 32 bit app, it will look for files from GAC in /usr/lib. There is no guarantee that GAC will be found.
By placing files in /usr/share GAC can always be found.
Obviously this is in discussion now (which is why I've invited Andrew Jorgensen from Novell to take part in the thread), but it would certainly make more sense to have them as .noarch packages and in /usr/share.
TTFN
Paul
Paul wrote:
Hi,
Mono (and mono-packages) are currently packaged to %{_libdir} as per the published guidelines for packaging.
There has been discussion, both recently and in the past, about moving mono to .noarch packages and placing them in /usr/share. The rational behind this is that .NET CIL is a non-architecture specific system which calls on a central repository of dlls held within GAC. It is a shared resource rather than a platform specific resource. It is also not a traditional library (.so).
While there is no arguing that .so (and standard linux library files) should remain in %{_libdir}, non-native libs should not live there; it pollutes and causes problems elsewhere. Simple example, if you live on a 64 bit box and install a prebuilt 32 bit app, it will look for files from GAC in /usr/lib. There is no guarantee that GAC will be found.
By placing files in /usr/share GAC can always be found.
Obviously this is in discussion now (which is why I've invited Andrew Jorgensen from Novell to take part in the thread), but it would certainly make more sense to have them as .noarch packages and in /usr/share.
The Fedora Packaging Guidelines for Mono justify the use of arch-specific libraries on the basis that ahead-of-time (AOT) compiled assemblies are arch-specific and must, if used, live in the same directory as their DLL/EXE counterparts. Ergo the DLL/EXE versions must also live in arch-specific directories.
https://fedoraproject.org/wiki/Packaging/Mono
Paul.
On Tue, 2008-09-16 at 13:36 +0100, Paul wrote:
he rational behind this is that .NET CIL is a non-architecture specific system which calls on a central repository of dlls held within GAC. It is a shared resource rather than a platform specific resource. It is also not a traditional library (.so).
Except that those files seem to be architecture specific...which is why we moved them to %{_libdir} in the first place.
~spot
Tom "spot" Callaway wrote:
On Tue, 2008-09-16 at 13:36 +0100, Paul wrote:
he rational behind this is that .NET CIL is a non-architecture specific system which calls on a central repository of dlls held within GAC. It is a shared resource rather than a platform specific resource. It is also not a traditional library (.so).
Except that those files seem to be architecture specific...which is why we moved them to %{_libdir} in the first place.
When researching this for the Guidelines, I found a thread on the Debian lists in which they decided to move from /usr/share to /usr/lib because of input from Miguel. I can find that discussion in their archives if needed but the gist of it was:
1) DLLs can call architecture specific code using architecture specific types and there's no good way to detect that the code is doing this without analyzing the source code. We don't want to inflict that on packagers. If there is an easily automated method for finding these cases, that would help here.
2) DLLs can be AOT-compiled. Those AOT-compiled bits have to live next to the architecture independent DLLs. If the AOT loading code was rewritten to be able to find the DLLs in a different place from the AOT compiled code or if the AOT compiled bits could have all the information necessary and not need to find the DLLs at all, then that would make this go away.
If someone's going to allocate resources to fixing these issues, make sure I dig up that Debian thread as there may be a third problem I'm not remembering at the moment.
-Toshio
packaging@lists.fedoraproject.org
-
Paul F. Johnson -
Paul Howarth -
Tom Callaway -
Toshio Kuratomi