[Mono-dev] Red Hat/Fedora packaging

Toshio Kuratomi a.badger at gmail.com
Tue May 12 08:43:24 EDT 2009


Vladimir Giszpenc wrote:
> The following was taken from https://fedoraproject.org/wiki/Packaging/Mono
> 
> * *
> 
> *File Locations***
> 
> Mono packages should install assemblies to %{_libdir} rather than
> /usr/lib or %{_datadir}. In most cases the preference is
> for %{_libdir}/PACKAGENAME. We use %{_libdir} because we do not consider
> mono packages to be noarch.
> 
> The main reason for this is that mono can ahead-of-time compile its
> assemblies into ELF shared objects. These AOTs have to exist in the same
> directory as their DLL/EXE counterparts otherwise mono cannot use them.
> Even if we, as packagers, choose not to create the AOT files when we
> build the mono rpms, the system administrator can choose to create them
> after install. Since there's no way to place the mono assemblies into an
> arch independent directory and the AOTs into arch dependent directories,
> the whole thing has to go into an arch dependent tree.
> 
>  
> 
> It really bothers me that Red Hat/Fedora considers CIL packages not to
> be noarch.  I would like to propose using the config file to allow
> relocating the aot-ed file to some arch dependent location.  The problem
> they have is that the aot-ed code must be side-by-side with the pre
> compiled assembly.
> 
>  
> 
> Could we use Foo.dll.config to have sections per architecture that tell
> the runtime where to load the aot-ed file from?
> 
> I don’t actually use aot-ed code.  I just want to get my package (exe)
> to be noarch.   Using Red Hat is not my choice so please don’t suggest
> that I use another distribution.  Please help me get these packaging
> guidelines changed.
> 
>  
Note that there's two reasons to consider the packages arch specific and
one thing to consider if the packages are noarch:

Reasons for arch specific:
* aot compiled code has to live alongside the CIL files.
* No one in Fedora has devised a way of telling when a CIL file depends
on something architecture specific (like calling out to native code that
uses different word sizes on different architectures).  This one might
be a misunderstanding or something that's actually easy to do.

The noarch difficulty:
* According to the FHS, if CIL files are architecture independent they
should live under /usr/share/ instead of under /usr/lib.

Note: For those who are unfamiliar with multilib, %{_libdir} != /usr/lib
on all arches.  On x86_64, %{_libdir} == /usr/lib64.  /usr/lib exists
there and has 32 bit versions of libraries for running 32 bit programs.

I'd love for this to be figured out upstream as we presently have to
patch things that install in /usr/lib to go to %{_libdir} (although the
prospect of patching things to go to %{_datadir} instead isn't anymore
appetizing.)

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090512/5fcfe853/attachment.bin 


More information about the Mono-devel-list mailing list