[Fedora-packaging] Changing default paths for mono packages

[Paul F. Johnson]

On Thu, 2011-06-02 at 23:39 +0200, Christian Krause wrote:
> Hi Toshio,
Hi,

> > Well, it seems like the problems with conflicts between x86 and x86_64 would
> > be solved by making noarch packages.  The splitting of packages is just
> 
> Since the mono runtime environment contains arch-dependent executables
> (e.g. /usr/bin/mono), it will never be possible to install both the x86
> and the x86_64 stack on x86_64. So multi-arch seems to be impossible
> with mono.

It is possible, but it's a pain. Effectively, you need to check
something in /proc (I think) to see the processor type. If it's 64 bit,
you direct to /usr/lib64 otherwise you point to /usr/lib (of course,
this would need altering for PPC/ARM etc)

> On the other hand, since the C# assemblies are exchangeable between x86
> and x86_64, it should be possible to have a shared /usr/lib directory
> even without splitting the packages.

No. That messes up the point of /usr/lib. Mono applications are arch
independent which means either the correct %{_libdir} (as with Python)
or /usr/share

> > making a noarch subpackage so it's pretty straightforward.  It doesn't seem
> > like too much overkill, is more correct as you point out, and is a natural
> > extension of the way pure C# would be packaged.
> 
> Hm, just because a package contains arch-dependent and arch-independent
> libraries, this does not automatically call for separating the
> arch-independent parts into noarch packages. Just look at all python or
> perl packages which come with e.g. arch-independent python/perl
> parts/libraries and additionally contain ELF binary parts or not
> splitted. These packages are just then arch-dependent.
> 
> So I currently don't see why we should do it otherwise for C# packages.

Right, let's clean this up....

AIUI, python applications are arch independent. The executable (script)
goes in %{_bindir}. This then links to the python libs in %{_libdir}. It
doesn't matter what the libs in %{_libdir} link to, the actual
application is noarch. If the python lib links to an ELF library via a
glue or anything else, that will be found in %{_libdir} - this has
always been the case. It doesn't change the point that the actual
application is noarch.

Mono applications are the same. The script is in %{_bindir} which links
to wherever it links to (for the example of monodevelop, it's in
%{_libdir}/monodevelop which is normally symlinked from
%{_libdir}/mono/monodevelop). By going to %{_libdir}/mono/monodevelop,
it's doing exactly the same as a python application. Everything in the
monodevelop directory is noarch. The stuff in gac et al, is not noarch,
contains glues etc - but that doesn't matter, it's the same reasoning as
python applications.

There could be an argument of splitting noarch and arch specific bits,
but this should not happen given the rational of mono.

> > I don't see anything else that might be problematic in there.
> 
> Can I treat this as the official approval from FPC - or how should I
> proceed from here? ;-)

With caution would be my advice...

PFJ

-- 
Vertraue mir, ich weiss, was ich mache...