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
Attachment:
pgpAcXDyWDK5c.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
