[Fedora-packaging] Changing default paths for mono packages

[James Antill]

On Thu, 2011-06-02 at 23:39 +0200, Christian Krause wrote:
> On 05/31/2011 11:43 PM, Toshio Kuratomi wrote:
> > On Tue, May 31, 2011 at 09:01:00PM +0200, Christian Krause wrote:
> >> Hi,
> >>
> >> On 05/31/2011 06:02 PM, Toshio Kuratomi wrote:
> 
> >> However, even if it would be easy for packages like "monodevelop", which
> >> contain only C# assemblies and no ELF libraries there may be problems
> >> with packages like f-spot, which contains mostly C# assemblies but also
> >> include one "glue code" ELF library. Should the package then be split?
> >> That sounds a little bit like overkill just for the purpose of having
> >> 100% pure correctness of the packages without solving any real problems.
> >> ;-)
> >>
> > 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.

 This is true for python too, but there is still some multilibness. But
even assuming that's true...

> 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.
[...]
> 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.

 A significant number of python packages are split (Eg. yum has it's
"native" parts in a separate package).
 One of the reasons for this is that if you have say f-spot-cmd and
f-spot, where just the former is native ... you get to save storing all
of the *.dll etc. files N times. This can add up quickly given a
significant number of packages and architectures.

> > OTOH, with other languages (for instance python) only some things end up
> > multilibbed.  For instance, python-libs (from the python package) is
> > multilib and pygtk2-devel is multilib (but not pygtk2 itself).
> > python-pycurl is an example of a package that is not multilibbed.  So... eh,
> > your argument makes enough sense to me.
> 
> Just to avoid misunderstandings: What do you specifically mean with
> multilibbed? The ability to install both packages (i686 and x86_64) on
> x86_64 without getting any conflicts?

 Yes.