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