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
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
