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.
> """
>
> 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.
;-)
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.
> 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
-----------
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