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