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
"CK" == Christian Krause chkr@fedoraproject.org writes:
CK> I have discussed this topic with upstream again, and there was an CK> agreement that mono assemblies are treated as platform independent CK> and so the original reason to change the paths is not valid anymore.
Then we should move them to /usr/share.
The point was that hardcoding /usr/lib is always wrong. If they're arch dependent, they should be in %{_libdir}. If not, /usr/share. So we asked which it was and got the current answer. If the answer is different, then we have another change to make but currently what upstream does isn't right in either case.
And, yes, python is still wrong in using /usr/lib the way it does. I'd hope that we could fix that with python3 but somehow that didn't work out.
- J<
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
On 05/31/2011 05:45 PM, Jason L Tibbitts III wrote:
And, lovely, crossposting to a list I can't post to.
Sorry for that. Postings from non-members were rejected due to the massive amount of spam. I have just allowed postings for non-members again (at least for this discussion).
Best regards, Christian
Hi,
On 05/31/2011 05:44 PM, Jason L Tibbitts III wrote:
"CK" == Christian Krause chkr@fedoraproject.org writes:
CK> I have discussed this topic with upstream again, and there was an CK> agreement that mono assemblies are treated as platform independent CK> and so the original reason to change the paths is not valid anymore.
Then we should move them to /usr/share.
The point was that hardcoding /usr/lib is always wrong. If they're arch dependent, they should be in %{_libdir}. If not, /usr/share. So we
Why? ;-) The FHS uses the following definitions:
/usr/lib : Libraries for programming and packages /usr/share : Architecture-independent data
Given just these definitions, libraries with byte code which needs an interpreter / runtime environment, can still be considered being libraries which would go into /usr/lib. "data" can also be interpreted like: additional data files which are needed to execute a program (like icons, game data, etc.). I haven not found any explicit rule that "library" only refers to native ELF binaries.
asked which it was and got the current answer. If the answer is different, then we have another change to make but currently what upstream does isn't right in either case.
Upstream would not agree with that statement.
The whole point of the suggested changes is to be closer to upstream.
The reasons are: - Fedora's way produces lots of unnecessary work - the changed paths causes lots of bugs - the patches are rejected upstream - upstream refuses to help with issues caused by changing the default paths - Fedora encourages the maintainers to stay close to upstream
Putting the C# assemblies into %{_datadir} would not solve these problems.
Best regards, Christian
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. """
- 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. ;-)
- 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
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. """
- 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.
- 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
On 05/31/2011 11:44 AM, Jason L Tibbitts III wrote:
And, yes, python is still wrong in using /usr/lib the way it does. I'd hope that we could fix that with python3 but somehow that didn't work out.
Huh? Python contains *both* noarch and arch specific libraries (e.g. .so's) which are collocated in the same directories. To the best of my knowledge there is no standard mechanism in Python which would allow segregating the noarch ans arch specific files into different search paths *and* properly resolve module loading when noarch and arch specific modules are interdependent by sub-path location.
FWIW, Java has a similar problem with noarch files (.class & .jar) and JNI native .so files. There was discussion in the Java SIG group a number of weeks back and I'm not sure there was resolution, what I do recall was there was decent amount of disagreement over the proper packaging approach.
Bottom line seems to be that we need to address the packaging issues of languages supporting a mix of byte compiled noarch libraries and arch specific "native" libraries at a higher level and then form language specific rules derived from the general principles.
What we don't want to continue doing is promulgating the band-aid inconsistent one-off rules, suggestions and domain specific policies. I've spent an unreasonable amount of time trying to deal with these issues and I can testify it's a mess and the whole problem seems poorly understood and our tools poorly equipped to deal with it.
To be perfectly honest if you ask me "multi-lib" is currently a hack with a lot of warts and dark corners because we tried to graft the concept of multi-lib on top of a tool chain and policies which were never meant to support the concept.
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
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
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.
On Thu, 2011-06-02 at 12:08 -0400, John Dennis wrote:
On 05/31/2011 11:44 AM, Jason L Tibbitts III wrote:
And, yes, python is still wrong in using /usr/lib the way it does. I'd hope that we could fix that with python3 but somehow that didn't work out.
Huh? Python contains *both* noarch and arch specific libraries (e.g. .so's) which are collocated in the same directories. To the best of my knowledge there is no standard mechanism in Python which would allow segregating the noarch ans arch specific files into different search paths *and* properly resolve module loading when noarch and arch specific modules are interdependent by sub-path location.
I'm not entirely sure what you are saying here, certainly python does have two paths currently:
% rpm -ql yum | fgrep sqlite /usr/lib/python2.7/site-packages/yum/sqlitesack.py /usr/lib/python2.7/site-packages/yum/sqlitesack.pyc /usr/lib/python2.7/site-packages/yum/sqlitesack.pyo % rpm -ql yum-metadata-parser | fgrep sqlite /usr/lib64/python2.7/site-packages/_sqlitecache.so /usr/lib64/python2.7/site-packages/sqlitecachec.py /usr/lib64/python2.7/site-packages/sqlitecachec.pyc /usr/lib64/python2.7/site-packages/sqlitecachec.pyo
...the remaining bug (for years now) is that our python packages uses "/usr/lib" instead of "/usr/share" for the noarch path.
packaging@lists.fedoraproject.org
-
Christian Krause -
James Antill -
Jason L Tibbitts III -
John Dennis -
Paul F. Johnson -
Toshio Kuratomi