[Fedora-packaging] Changing default paths for mono packages

Tue May 31 21:43:13 UTC 2011

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20110531/b5529874/attachment.bin 