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
(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 chkr@fedoraproject.orgwrote:
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 mono@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/mono
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
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
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
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
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
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
mono@lists.stg.fedoraproject.org
-
Christian Krause -
Drew Kwashnak -
Timur Kristóf -
Toshio Kuratomi