Deprecating multiarch support for mono in Fedora

[Christian Krause]

Hi,

The way how mono is packaged in Fedora is uncommon with respect to
mono's default search paths:

In order to provide multi-arch support  (32-bit and 64-bit packages
can be both installed on x86_64 systems), the standard mono's libdir
/usr/lib was changed to %{_libdir} (which is /usr/lib64 on x86_64).

Since this contradicts upstream's understanding of the directory
structure, this causes lots of unnecessary work for the maintainers and
quite a couple of bug reports due to uncaught uses of these default
paths within the mono packages. Nearly every mono package must be
adjusted and so the majority of all patches for mono consists solely of
%{_libdir} "fixes". Since it looks like that upstream (not only
mono-core, basically all mono-based packages) does not agree to these
changes, non of these patches are accepted upstream.

However, solving this issue would include to loose the ability to use
32bit parts of the mono stack in x86-64 - a feature which never worked
correctly and is not available for perl or python either.

Please see all details on the following wiki page I want to send in as
"feature" suggestion for F16:

https://fedoraproject.org/wiki/User:Chkr/MonoMultiarchChanges

My plan is to run this by the following groups to get their agreement:

- this mailing list ;-)
So please provide any feedback (positive and negative!) to the suggested
changes!

- Fedora packaging committee
Since the change affects how /usr/lib and /usr/lib64 are used for
mono-based packages in Fedora, I'd like to get their agreement, too.

- FEScO
For the final approval.

Please let me know you thoughts!

Best regards,
Christian

[Drew Kwashnak]

(Please forgive me if this is a simple question.)
Just to make sure I understand this, this change would drop the ability to
run 32 bit Mono of 64 bit systems, but 32 bit Mono would run on 32 bit
systems and 64 bit mono would run on 64 bit systems?

Drew

On Mon, May 2, 2011 at 4:57 PM, Christian Krause wrote:
> Hi,
>
> The way how mono is packaged in Fedora is uncommon with respect to
> mono's default search paths:
>
> In order to provide multi-arch support  (32-bit and 64-bit packages
> can be both installed on x86_64 systems), the standard mono's libdir
> /usr/lib was changed to %{_libdir} (which is /usr/lib64 on x86_64).
>
> Since this contradicts upstream's understanding of the directory
> structure, this causes lots of unnecessary work for the maintainers and
> quite a couple of bug reports due to uncaught uses of these default
> paths within the mono packages. Nearly every mono package must be
> adjusted and so the majority of all patches for mono consists solely of
> %{_libdir} "fixes". Since it looks like that upstream (not only
> mono-core, basically all mono-based packages) does not agree to these
> changes, non of these patches are accepted upstream.
>
> However, solving this issue would include to loose the ability to use
> 32bit parts of the mono stack in x86-64 - a feature which never worked
> correctly and is not available for perl or python either.
>
> Please see all details on the following wiki page I want to send in as
> "feature" suggestion for F16:
>
> https://fedoraproject.org/wiki/User:Chkr/MonoMultiarchChanges
>
> My plan is to run this by the following groups to get their agreement:
> this mailing list ;-)
>
> So please provide any feedback (positive and negative!) to the suggested
> changes!
> Fedora packaging committee
>
> Since the change affects how /usr/lib and /usr/lib64 are used for
> mono-based packages in Fedora, I'd like to get their agreement, too.
> FEScO
>
> For the final approval.
>
> Please let me know you thoughts!
>
> Best regards,
> Christian
> _______________________________________________
> mono mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/mono

[Christian Krause]

Hi Drew,

On 05/03/2011 02:10 AM, Drew Kwashnak wrote:
> (Please forgive me if this is a simple question.)
> Just to make sure I understand this, this change would drop the ability to run
> 32 bit Mono of 64 bit systems, but 32 bit Mono would run on 32 bit systems and
> 64 bit mono would run on 64 bit systems?

Yes, that's correct.

We would only loose the ability to install 32 bit packages on x86_64. But IMHO 
that was never really supported even if some mono-based i686 packages were in 
the x86_64 repo. So I don't think that this change will have an impact to 99% of 
the users... ;-)

Best regards,
Christian

[Timur Kristóf]

Christian, all in all I have to agree with your proposed idea. It makes 
great sense and should have been done a long time ago.
> In order to provide multi-arch support  (32-bit and 64-bit packages
> can be both installed on x86_64 systems), the standard mono's libdir
> /usr/lib was changed to %{_libdir} (which is /usr/lib64 on x86_64).

Yeah, that's a huge hack.
> Since this contradicts upstream's understanding of the directory
> structure, this causes lots of unnecessary work for the maintainers and
> quite a couple of bug reports due to uncaught uses of these default
> paths within the mono packages. Nearly every mono package must be
> adjusted and so the majority of all patches for mono consists solely of
> %{_libdir} "fixes".

Indeed. And it can lead to unforseen bugs that nor upstream, neither the 
packagers can fix.
> Since it looks like that upstream (not only
> mono-core, basically all mono-based packages) does not agree to these
> changes, non of these patches are accepted upstream.

Just as with every other package, we should provide it as upstream.
> However, solving this issue would include to loose the ability to use
> 32bit parts of the mono stack in x86-64

A usecase which doesn't make sense anyway. We won't lose anything by 
letting it go.My plan is to run this by the following groups to get 
their agreement:
> Please let me know you thoughts!

I think this is a very good idea and it is definitely worth implementing.
Basically all we need to do is remove a bunch of 'sed' commands, is that 
right?

On 05/03/2011 02:10 AM, Drew Kwashnak wrote:
> Just to make sure I understand this, this change would drop the 
> ability to run 32 bit Mono of 64 bit systems, but 32 bit Mono would 
> run on 32 bit systems and 64 bit mono would run on 64 bit systems?

As I understand it, it means that you could no longer have both the 
32-bit and the 64-bit versions of Mono installed on the same system. So 
32-bit Mono would run on 32-bit systems (as it does now), and on 64-bit 
you could install either the 32-bit or the 64-bit version, just not both 
at the same time.

Cheers,
Timur

[Toshio Kuratomi]

On Tue, May 03, 2011 at 01:46:51PM +0200, Timur Kristóf wrote:
> Christian, all in all I have to agree with your proposed idea. It makes 
> great sense and should have been done a long time ago.
> > In order to provide multi-arch support  (32-bit and 64-bit packages
> > can be both installed on x86_64 systems), the standard mono's libdir
> > /usr/lib was changed to %{_libdir} (which is /usr/lib64 on x86_64).
>
> Yeah, that's a huge hack.

This isn't really the reason that we ship in %{_libdir}.  It's that upstream
mono convinced Debian that mono libraries should be treated as arch
specific.  If they're arch specific then they need to go in %{_libdir} on
Fedora.
> > Since this contradicts upstream's understanding of the directory
> > structure, this causes lots of unnecessary work for the maintainers and
> > quite a couple of bug reports due to uncaught uses of these default
> > paths within the mono packages. Nearly every mono package must be
> > adjusted and so the majority of all patches for mono consists solely of
> > %{_libdir} "fixes".
>
> Indeed. And it can lead to unforseen bugs that nor upstream, neither the 
> packagers can fix.
> > Since it looks like that upstream (not only
> > mono-core, basically all mono-based packages) does not agree to these
> > changes, non of these patches are accepted upstream.
>
> Just as with every other package, we should provide it as upstream.

This is not true. There are still C libraries in Fedora which are unaware of
how to handle %{_libdir} upstream nad must be patched by us, for instance.

-Toshio

[Toshio Kuratomi]

On Mon, May 02, 2011 at 10:57:10PM +0200, Christian Krause wrote:
> this mailing list ;-)
>
> So please provide any feedback (positive and negative!) to the suggested
> changes!
> Fedora packaging committee
>
> Since the change affects how /usr/lib and /usr/lib64 are used for
> mono-based packages in Fedora, I'd like to get their agreement, too.
> FEScO
>
> For the final approval.

Note that generally changes to the Packaging Guidelines do not go to FESCo.
If the FPC does not agree with your change to the Guidelines, then you can
escalate it to FESCo to see if they'll overrule the FPC.

I think that the basic thing that would need to be proved for either the FPC
or FESCo is whether we should stop considering the libraries to be
arch-specific.  If the reasoning from upstream mono remains the same that
they belong in an arch-specific directory then I doubt that FPC would
consider moving them out of %{_libdir} and I doubt that FESCo would overrule
FPC in that case.

If there's new reasoning that says that the libraries are
arch independent, then the FPC's next question would probably be why they
don't belong in %{_datadir} (where Debian originally wanted to place them
before being convinced to treat them as arch specific).  I don't know how
stringent the FPC would be about requiring %{_datadir} should the libraries
be arch independent, though.

-Toshio

[Christian Krause]

Hi Toshio,

thanks for you comments!

On 05/04/2011 03:36 AM, Toshio Kuratomi wrote:
> On Mon, May 02, 2011 at 10:57:10PM +0200, Christian Krause wrote:
> > FEScO
> >
> > For the final approval.
>
> Note that generally changes to the Packaging Guidelines do not go to FESCo.
> If the FPC does not agree with your change to the Guidelines, then you can
> escalate it to FESCo to see if they'll overrule the FPC.

Ok - I thought that this could be treated as some kind of feature that
needed FESCo approval... But if FPC would be sufficient that's ok.
> I think that the basic thing that would need to be proved for either the FPC
> or FESCo is whether we should stop considering the libraries to be
> arch-specific.  If the reasoning from upstream mono remains the same that
> they belong in an arch-specific directory then I doubt that FPC would
> consider moving them out of %{_libdir} and I doubt that FESCo would overrule
> FPC in that case.

Just to avoid any misunderstanding: the suggestion is to move the mono
byte code from %{_libdir} to /usr/lib. So the change would be only for
x86_64.

At least most other distributions like OpenSUSE or Debian treat the mono
bytecode (the libraries (*.dll) as well as the executables (*.exe)) as
noarch, but place them in /usr/lib anyway:

https://build.opensuse.org/package/binary?arch=x86_64&filename=mono-addi...
> If there's new reasoning that says that the libraries are
> arch independent, then the FPC's next question would probably be why they
> don't belong in %{_datadir} (where Debian originally wanted to place them

I've just checked this: Debian does not place the files in %{_datadir}.
Just recently it looks like that they have moved the gac to a more
generic directory /usr/lib/cli and before it was in /usr/lib/mono/gac -
even in their 64bit packages:
http://packages.debian.org/sid/amd64/libgtk2.0-cil/filelist

OpenSuse:
https://build.opensuse.org/package/binary?arch=x86_64&filename=gtk-sharp...

So far it looks for me, that Fedora is the only distribution which uses
%{_libdir} and causes these huge amount of strange patches. Since all
upstream developers of mono-based packages assume the placement in
/usr/lib the paths (e.g. for extensions etc.) are even hard-coded
sometimes or put together at run-time. Finding all of these places is a
tedious and self-defeating work which actually does not solve any
real-world problems but is only necessary because of our "self-made"
problem by diverging from the mono's standard paths.
> before being convinced to treat them as arch specific).  I don't know how
> stringent the FPC would be about requiring %{_datadir} should the libraries
> be arch independent, though.

AFAIK the byte code is mostly compatible, but I have heard that the mono
developers don't guarantee it.

Nevertheless, I think that's a judgement call here:

- on one side Fedora wants to be close to the FHS (arch-independent
files should go to /usr/share, package should be noarch then, etc.)

- on the other side Fedora encourages the packagers to stay close to
upstream and provide all changes as patches to upstream

- in this specific case, Fedora's way is different to
a) other distributions
b) upstream

- as a result, no patches can be upstreamed, upstream does not care
about our problems, and the packagers have to do a lot of unnecessary work

Given all the pros and cons I'm quite convinced that Fedora should
change the way how mono is packaged.

Toshio, could I convince you that the proposed way would be the "the
right way to go" for Fedora? ;-) If not, what's missing?

Best regards,
Christian

[Toshio Kuratomi]

Discussed on IRC.  Christian is going to talk to Miguel/upstream mono devel
and hopefully get them to officially acknowledge that the arch-specific
arguments listed here:
  http://lists.alioth.debian.org/pipermail/pkg-mono-devel/2005-February/000370...

are no longer valid.  With that we can have a discussion in the FPC about
using /usr/lib instead of %{_libdir}.  If we fail to get that... well, we'll
cross that bridge if we get to it.

-Toshio