Packaging mono - RFC

[Paul F. Johnson]

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
-- 
Sie können mich aufreizen und wirklich heiß machen!

[Paul Howarth]

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.

[Tom Callaway]

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

[Toshio Kuratomi]

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