[Fedora-packaging] Mono Packaging Issues

[Toshio Kuratomi]

On Wed, 2006-06-14 at 19:43 +0100, Paul wrote:
> Hi,
> 
> I've asked about the architecture agnostisism on the mono-developers
> list and had this back
> 
> 8-->
> On Wed, 2006-06-14 at 09:49 +0100, PFJ wrote:
> The best example of a "platform specific" assembly would be a "mixed
> mode" assembly, in which actual x86/AMD64/Itanium/etc. code is placed
> into the assembly along with the platform agnostic CIL code.
> 
> However, only .NET tools can create such mixed mode assemblies, and Mono
> doesn't support their execution on any platform, so they're currently
> not a concern (and likely won't ever be, for a variety of reasons).
> 
Good.  So as long as all source is rebuilt with mono we don't have to
worry about this issue.  DLLs and EXEs will contain CIL only.

> The only thing left to determine whether an assembly is platform
> specific is the use of Platform Invoke (P/Invoke), and this is _not_
> trivial, as "portable" P/Invoke code can be written, but
> platform-specific platform code can also be written.  Classic example:
> `struct stat' in C#:
> 
>         public struct stat {
>                 public ulong st_dev, st_ino;
>                 public uint st_mode;
>                 private uint _padding_;
>                 public ulong st_nlink, st_uid, st_gid, st_rdev;
>                 public long st_size, st_blksize, st_blocks, st_atime,
>                         st_mtime, st_ctime;
>         }
> 
> Question: is that structure definition portable for use with fstat(2)?
> 
> Answer: Maybe. :-)  It should work on 64-bit ABIs (since long/ulong are
> 64-bit integer types), but it will fail badly on 32-bit ABIs, and it
> will fail on any ABI in which the member ordering differs.
> Consequently, such a structure would be platform specific if used with a
> DllImport statement, but there is NO EASY WAY for a program to make this
> determination. :-/
> 
> (Plus, it can get more complicated, particularly if such a structure is
> instead used with some native library which will accept that structure,
> such as Mono.Posix.dll & libMonoPosixHelper.so, which uses a 64-bit ABI
> throughout, and libMonoPosixHelper.so converts this to a 32-bit ABI as
> appropriate.)
> 
> So it's easiest to assume that all CIL code is platform agnostic.
> 
I don't see how the OTP came to this conclusion.  The example is
illustrating that there is no easy way to tell if CIL code is platform
specific or platform independent.  In the absence of knowing that, we
should be assuming the code is platform specific, not platform agnostic
as he suggests.

> I would suggest looking at what SuSE and Debian/Ubuntu have done with
> this, as they have all encountered these issues.  Following in their
> footsteps would help consistency, and make it easier to repackage
> existing programs.
> 
> I believe that they currently use /usr/lib for everything.
> 
AFAIK Debian does not have multilib so our separation of %{_libdir}
from /usr/lib does not occur there.  I don't know about SuSE.

> However, this gets considerably more complicated, as applications may
> bundle native libraries with them -- take Blam! and F-Spot as examples:
[snip example]
> The *.dll and *.exe files may be platform agnostic, but the *.so* files
> certainly are NOT.
> 
> So the easiest solution may be to check to see if any native libraries
> are bundled with the app, and if that's the case stick it under the
> appropriate /usr/lib or /usr/lib64 directory.  Otherwise, stick
> with /usr/lib.

Given that it is difficult to determine whether a .dll contains platform
specific or platform agnostic code, I'd argue that everything should go
to %{_libdir}.  My reading of Debian's switch from %{_datadir} to
%{_libdir} implies that they think the same way.

BTW: Here's Debian's guidelines.  All DLLs they reference goes to their
arch specific directory (Remember, they are non-multilib):

The package's applications, libraries and meta-data must be installed
into /usr/lib/packagename.

Libraries that will be installed into the GAC should be installed
into /usr/lib/cli/packagename-X.Y (for more details about the X.Y
version see GAC versioning). The commonly seen /usr/lib/mono/packagename
path should only be used for Mono project packages.

Never install native "glue" libraries into /usr/lib, instead install
them at /usr/lib/cli/packagename-X.Y. When moving libraries update the
references to the new location using a DLL Map. See the Mono DLL maps
secion for an example.

The only exception here is for native libraries that are of wider use;
can be used other packages. Native libraries should be packaged
according to the Library Packaging Guide in a Debain Policy conformant
way.

Never ever install application files (.exe) directly into /usr/bin.
Instead create a wrapper script into /usr/bin to allow them to be run
without the .exe suffix.


http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-file-locations

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20060614/90cc417b/attachment.sig>