Hi Toshio,
On 05/31/2011 11:43 PM, Toshio Kuratomi wrote:
On Tue, May 31, 2011 at 09:01:00PM +0200, Christian Krause wrote:
> Hi,
>
> On 05/31/2011 06:02 PM, Toshio Kuratomi wrote:
> 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
Since the mono runtime environment contains arch-dependent executables
(e.g. /usr/bin/mono), it will never be possible to install both the x86
and the x86_64 stack on x86_64. So multi-arch seems to be impossible
with mono.
On the other hand, since the C# assemblies are exchangeable between x86
and x86_64, it should be possible to have a shared /usr/lib directory
even without splitting the packages.
If I have misunderstood the intention, please explain the use case in
detail.
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.
Hm, just because a package contains arch-dependent and arch-independent
libraries, this does not automatically call for separating the
arch-independent parts into noarch packages. Just look at all python or
perl packages which come with e.g. arch-independent python/perl
parts/libraries and additionally contain ELF binary parts or not
splitted. These packages are just then arch-dependent.
So I currently don't see why we should do it otherwise for C# packages.
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.
Just to avoid misunderstandings: What do you specifically mean with
multilibbed? The ability to install both packages (i686 and x86_64) on
x86_64 without getting any conflicts?
> 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..
>
>
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 have double-checked this: that is just a data structure containing
some strings about the build host. Some C# projects use such kind of
data structure and customize the strings during build time. AFAIK it has
no run-time impact at all.
I don't see anything else that might be problematic in there.
Can I treat this as the official approval from FPC - or how should I
proceed from here? ;-)
Best regards,
Christian