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