5:07 p.m.
Hi,
After discussing the topic on mono-devel and with the upstream mono
developers I would like to run the following suggestions by the FPC:
The way how mono is packaged in Fedora is uncommon with respect to
mono's default search paths. 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 it 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 nor do we get any
help from upstream if the issues are caused by Fedora's directory structure.
However, solving this issue (and reverting the change to mono's default
paths) 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.
Fedora's decision to change the default paths was based on a statement
from the mono developers a couple of years ago regarding the
architecture-independence of the mono assemblies. I have discussed this
topic with upstream again, and there was an agreement that
mono assemblies are treated as platform independent and so the original
reason to change the paths is not valid anymore.
Please see all details on the following wiki:
https://fedoraproject.org/wiki/User:Chkr/MonoMultiarchChanges
So my question to the FPC:
Do you agree with the suggested changes?
Best regards,
Christian
11:02 a.m.
New subject: [Fedora-packaging] Changing default paths for mono packages
On Tue, May 31, 2011 at 12:07:17AM +0200, Christian Krause wrote:
Please see all details on the following wiki:
https://fedoraproject.org/wiki/User:Chkr/MonoMultiarchChanges
So my question to the FPC:
Do you agree with the suggested changes?
This section is a bit unclear to me:
"""
Reverting this decision and using again mono's standard search path /usr/lib
would result in conflicts between i686 and x86_64 packages because both
would contain the same files (possibly with different content). That means,
that we would have to prevent that any mono i686 package would be drawn into
the x86_64 repos and so we would 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 other run-time environments like perl or python either.
"""
1) We should be creating noarch packages (not x86 and x86_64 specific
packages) if these packages contain architecture independent code, correct?
2) This section says that the same files might have different content. Do
you have a list of the things that cause differences between compilations on
the different architectures? If it's just things like timestamps, that
should be fine as those won't cause problems when trying to run them on
other architectures. But I'm not sure if that's pretty much what it's
restricted to.
-Toshio
2:01 p.m.
New subject: [Fedora-packaging] Changing default paths for mono packages
Hi,
On 05/31/2011 06:02 PM, Toshio Kuratomi wrote:
This section is a bit unclear to me:
"""
Reverting this decision and using again mono's standard search path /usr/lib
would result in conflicts between i686 and x86_64 packages because both
would contain the same files (possibly with different content). That means,
that we would have to prevent that any mono i686 package would be drawn into
the x86_64 repos and so we would 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 other run-time environments like perl or python either.
"""
1) We should be creating noarch packages (not x86 and x86_64 specific
packages) if these packages contain architecture independent code, correct?
In general yes. ;-) That's the way how OpenSUSE handles it.
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.
;-)
2) This section says that the same files might have different
content. Do
you have a list of the things that cause differences between compilations on
No, I don't have a specific list.
the different architectures? If it's just things like
timestamps, that
should be fine as those won't cause problems when trying to run them on
other architectures. But I'm not sure if that's pretty much what it's
restricted to.
Given all information I got so far the assemblies should be compatible.
To verify this I have just tested it with f-spot:
On an x86_64 system with f-spot installed I have copied all C#
assemblies from the i686 package into the same location where the x86_64
package had put them. F-spot still worked fine.
So yes, the C# assemblies differ on binary level, but they are
compatible between i686 and x86_64.
I have also verified this with the mono disassembler:
----------------------------------------------
# diff -u <(monodis
/tmp/f-spot-0.8.2-1.fc14.i686/usr/lib/f-spot/TagLib.dll) <(monodis
/tmp/f-spot-0.8.2-1.fc14.x86_64/usr/lib64/f-spot/TagLib.dll)
--- /proc/self/fd/63 2011-05-31 20:57:01.172361683 +0200
+++ /proc/self/fd/62 2011-05-31 20:57:01.172361683 +0200
@@ -20,9 +20,9 @@
.custom instance void class
ApplicationBuildInformationAttribute::'.ctor'(string, string, string,
string) = (
01 00 0E 73 6F 75 72 63 65 2D 74 61 72 62 61 6C //
...source-tarbal
- 6C 09 6C 69 6E 75 78 2D 67 6E 75 04 69 33 38 36 //
l.linux-gnu.i386
- 17 32 30 31 30 2D 31 32 2D 33 30 20 31 39 3A 34 //
.2010-12-30 19:4
- 35 3A 34 37 20 55 54 43 00 00 ) //
5:47 UTC..
+ 6C 09 6C 69 6E 75 78 2D 67 6E 75 06 78 38 36 5F //
l.linux-gnu.x86_
+ 36 34 17 32 30 31 30 2D 31 32 2D 33 30 20 31 39 //
64.2010-12-30 19
+ 3A 34 35 3A 33 32 20 55 54 43 00 00 ) //
:45:32 UTC..
.custom instance void class
[mscorlib]System.Reflection.AssemblyTitleAttribute::'.ctor'(string) =
(01 00 06 46 2D 53 70 6F 74 00 00 ) // ...F-Spot..
@@ -51,7 +51,7 @@
.hash algorithm 0x00008004
.ver 0:8:0:0
}
-.module TagLib.dll // GUID = {0FA349CD-45CF-4BFE-ACE9-D11F3234C49E}
+.module TagLib.dll // GUID = {BFB9521F-4DBB-4D35-8CD0-CBDC908E0D54}
.namespace TagLib.Aac
----------------------------------------------
Best regards,
Christian
4:43 p.m.
New subject: [Fedora-packaging] Changing default paths for mono packages
On Tue, May 31, 2011 at 09:01:00PM +0200, Christian Krause wrote:
Hi,
On 05/31/2011 06:02 PM, Toshio Kuratomi wrote:
> This section is a bit unclear to me:
> """
> Reverting this decision and using again mono's standard search path /usr/lib
> would result in conflicts between i686 and x86_64 packages because both
> would contain the same files (possibly with different content). That means,
> that we would have to prevent that any mono i686 package would be drawn into
> the x86_64 repos and so we would 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 other run-time environments like perl or python either.
> """
>
> 1) We should be creating noarch packages (not x86 and x86_64 specific
> packages) if these packages contain architecture independent code, correct?
In general yes. ;-) That's the way how OpenSUSE handles it.
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
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.
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.
> 2) This section says that the same files might have different
content. Do
> you have a list of the things that cause differences between compilations on
No, I don't have a specific list.
> the different architectures? If it's just things like timestamps, that
> should be fine as those won't cause problems when trying to run them on
> other architectures. But I'm not sure if that's pretty much what it's
> restricted to.
Given all information I got so far the assemblies should be compatible.
To verify this I have just tested it with f-spot:
On an x86_64 system with f-spot installed I have copied all C#
assemblies from the i686 package into the same location where the x86_64
package had put them. F-spot still worked fine.
So yes, the C# assemblies differ on binary level, but they are
compatible between i686 and x86_64.
I have also verified this with the mono disassembler:
----------------------------------------------
# diff -u <(monodis
/tmp/f-spot-0.8.2-1.fc14.i686/usr/lib/f-spot/TagLib.dll) <(monodis
/tmp/f-spot-0.8.2-1.fc14.x86_64/usr/lib64/f-spot/TagLib.dll)
--- /proc/self/fd/63 2011-05-31 20:57:01.172361683 +0200
+++ /proc/self/fd/62 2011-05-31 20:57:01.172361683 +0200
@@ -20,9 +20,9 @@
.custom instance void class
ApplicationBuildInformationAttribute::'.ctor'(string, string, string,
string) = (
01 00 0E 73 6F 75 72 63 65 2D 74 61 72 62 61 6C //
...source-tarbal
- 6C 09 6C 69 6E 75 78 2D 67 6E 75 04 69 33 38 36 //
l.linux-gnu.i386
- 17 32 30 31 30 2D 31 32 2D 33 30 20 31 39 3A 34 //
.2010-12-30 19:4
- 35 3A 34 37 20 55 54 43 00 00 ) //
5:47 UTC..
+ 6C 09 6C 69 6E 75 78 2D 67 6E 75 06 78 38 36 5F //
l.linux-gnu.x86_
+ 36 34 17 32 30 31 30 2D 31 32 2D 33 30 20 31 39 //
64.2010-12-30 19
+ 3A 34 35 3A 33 32 20 55 54 43 00 00 ) //
:45:32 UTC..
.custom instance void class
[mscorlib]System.Reflection.AssemblyTitleAttribute::'.ctor'(string) =
(01 00 06 46 2D 53 70 6F 74 00 00 ) // ...F-Spot..
@@ -51,7 +51,7 @@
.hash algorithm 0x00008004
.ver 0:8:0:0
}
-.module TagLib.dll // GUID = {0FA349CD-45CF-4BFE-ACE9-D11F3234C49E}
+.module TagLib.dll // GUID = {BFB9521F-4DBB-4D35-8CD0-CBDC908E0D54}
.namespace TagLib.Aac
-----------
Huh. That linux-gnu.i386 vs linux-gnu.x86_64 line seems a bit fishy but
apparently that's only informational, mono isn't doing anything with it?
I don't see anything else that might be problematic in there.
-Toshio
4:39 p.m.
New subject: [Fedora-packaging] Changing default paths for mono packages
Hi Toshio,
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.
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.
If I have misunderstood the intention, please explain the use case in
detail.
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.
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?
> I have also verified this with the mono disassembler:
> ----------------------------------------------
> # diff -u <(monodis
> /tmp/f-spot-0.8.2-1.fc14.i686/usr/lib/f-spot/TagLib.dll) <(monodis
> /tmp/f-spot-0.8.2-1.fc14.x86_64/usr/lib64/f-spot/TagLib.dll)
> --- /proc/self/fd/63 2011-05-31 20:57:01.172361683 +0200
> +++ /proc/self/fd/62 2011-05-31 20:57:01.172361683 +0200
> @@ -20,9 +20,9 @@
>
> .custom instance void class
> ApplicationBuildInformationAttribute::'.ctor'(string, string, string,
> string) = (
> 01 00 0E 73 6F 75 72 63 65 2D 74 61 72 62 61 6C //
> ...source-tarbal
> - 6C 09 6C 69 6E 75 78 2D 67 6E 75 04 69 33 38 36 //
> l.linux-gnu.i386
> - 17 32 30 31 30 2D 31 32 2D 33 30 20 31 39 3A 34 //
> .2010-12-30 19:4
> - 35 3A 34 37 20 55 54 43 00 00 ) //
> 5:47 UTC..
> + 6C 09 6C 69 6E 75 78 2D 67 6E 75 06 78 38 36 5F //
> l.linux-gnu.x86_
> + 36 34 17 32 30 31 30 2D 31 32 2D 33 30 20 31 39 //
> 64.2010-12-30 19
> + 3A 34 35 3A 33 32 20 55 54 43 00 00 ) //
> :45:32 UTC..
>
>
Huh. That linux-gnu.i386 vs linux-gnu.x86_64 line seems a bit fishy but
apparently that's only informational, mono isn't doing anything with it?
I have double-checked this: that is just a data structure containing
some strings about the build host. Some C# projects use such kind of
data structure and customize the strings during build time. AFAIK it has
no run-time impact at all.
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? ;-)
Best regards,
Christian
5:19 a.m.
New subject: [Fedora-packaging] Changing default paths for mono packages
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...
1:46 p.m.
New subject: [Fedora-packaging] Changing default paths for mono packages
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.
4719
days inactive
4723
days old
6 comments
4 participants
participants (4)
-
Christian Krause -
James Antill -
Paul F. Johnson -
Toshio Kuratomi