[Fedora-packaging] Mono Packaging Issues

Toshio Kuratomi toshio at tiki-lounge.com
Wed Jun 14 07:20:17 UTC 2006

On Tue, 2006-06-13 at 19:25 -0500, Tom 'spot' Callaway wrote:
> On Mon, 2006-06-12 at 22:41 -0700, Toshio Kuratomi wrote:
> > My understanding is .dlls and .exes are architecture independent.
> This doesn't sound right to me. That doesn't mean that it isn't right,
> it just sounds weird.
If you've gotten to my latest message, you'll see I'm partially wrong
about this.

> file says that the mono dll files are:
> MS-DOS executable PE  for MS Windows (DLL) (console) Intel 80386 32-bit
> and file thinks that the mono exe files are:
> MS-DOS executable PE  for MS Windows (console) Intel 80386 32-bit
I believe that most of those dll and exe's are compiled to CIL (Common
Intermediate Language) which is then run by the CLR (in our case, mono)
similar to how java bytecode is run on the java runtime.

The PE is a container for the CIL vaguely similar to a jar file being a
renamed zip.

> Now, my understanding is that mono uses these DLL files as libraries,
> the EXE files as binaries. Are they compiled from source, or provided as
> is for use? If they're not compiled from source, this seems like a
> violation of Fedora policies (no binary only bits, please). 
In the boo package review there was one revision where the upstream
tarball was all precompiled .dlls and .exes.  After pointing this out,
the packager (Paul Johnson) found the tarball with source and packaged
that instead.  If it's common for upstream projects to distribute both
source and binary versions of their mono packages we'll have to be
vigilant about checking the source tarballs really contain sources and
not precompiled CIL PEs that install with make install.

> Presuming that they are compiled from source, they should be
> architecture specific. I did not think that C# was an interpreted
> language like python/perl... is it more like Java (runtime)?
It's similar to Java byte code.  However, if I'm reading Miguel's post
to the Debian list correctly, the PE's can become non-portable if they
consume functions from native libraries.  I'm unclear whether this is
something that happens when the developer writes the code or when it is

> > Should they end up in %{_libdir} or always end up in /usr/lib?  Fedora's
> > Python and Perl place arch independent data into /usr/lib, (I assume so
> > that they can be noarch) should mono as well? 
> Well, there are several questions there:
> 1. Are the DLLs and EXEs truly architecture independent?
At this point, the answer is, they may or may not be and I haven't run
across an easy way to check yet.  This is one of the reasons Debian has
changed their mind about putting them into %{_datadir}.

The other reeason is that the .dlls can be precompiled to native code to
make startup quicker.  It seems that at the time Debian changed away
from %{_datadir}, these precompiled libraries had to be placed alongside
the .dlls.  This would obviously be wrong for %{_datadir}.

> 2. Are the EXEs used like binaries? (They certainly seem to be)
Yes.  But the standard usage seems to be to include a script that is
installed to %{_bindir} and invoked the application where it resides
with the rest of the code.  I know of some python applications (rpmlint)
and java applications (azureus) that do the same thing.

> 3. How much will these mono apps break if we move the EXE location to
> %{_bindir}? (In my tests with tomboy, it seems to work fine if i move
> the EXE to %{_bindir} and edit the /usr/bin/tomboy wrapper script)
I don't know.  It's interesting to note that Debian was placing the
EXE's into %{_datadir} and writing a wrapper script to place in
%{_bindir} before they started discussing this with Miguel.  In that
discussion they found that upstream projects were being encouraged to
write their own wrappers and put the EXEs into /usr/lib (I don't know if
this was %{_libdir} or /usr/lib).

Note: I just moved banshee.exe to /var/tmp and changed /usr/bin/banshee
to point at it.  /usr/bin/banshee fails with an error that it could not
find Banshee.Base.  Banshee.Base.dll lives in %{_libdir}/banshee/ which
is normally where banshee.exe would be.

> 4. How much will mono (and its app) go nuts if we move the DLLs to
> to /usr/share ?
Since it seems there's no good way to tell if a .dll is dependent on the
arch or not, I'm withdrawing the idea of moving them to %{_datadir} so
this question is now moot.  I presently think they should go to
%{_libdir} (rather than /usr/lib where Core's mono package currently

> 4. How much will upstream (and unpackaged mono apps built from source)
> go nuts if we move our packaged mono bits out of the fake /usr/lib tree?
This mailing list post[1]_ says that PLD has been using %{_libdir} since
before 2005 and feels that upstream accepts their position.  Debian was
using %{_datadir} and Miguel gave them reasons he thought that was
wrong.  They seem to have changed to using /usr/lib but I'm unclear
whether /usr/lib == %{_libdir} or the way we use /usr/lib in Fedora
multilib (does Debian have multilib?)


> Let's leave perl and python out of this for the time being and focus on
> mono, where we have the opportunity to do things "correctly" early on,
> without several years of baggage and precedence.
True.  Although we'd still have upstream to shift to a new location.

> >  All the *-sharp packages
> > on my system currently follow this convention but beagle, tomboy, and
> > banshee end up in %{_libdir}. 
> Well, to be more specific, they end up in: %{_libdir}/%{name}

> > If we separate applications and libraries, how do we determine
> > which .dlls belong in an application directory and which belong in a
> > library directory? 
> I'm hoping this is as clear cut as "DLL == library, EXE == binary".
I think my Banshee experiment shows this is harder than that.  My guess
is if we separate banshee.exe from the DLLs it's intended to reside in
the same directory with, then those DLLs need to be registered with the
GAC.  If we do that are we placing something that isn't intended to be
shared into a shared area?

> > What are the easy ways to detect this issue?
> Man, I really don't think there are easy ways to detect this. Is a
> package including a DLL file that exists in another package?
> > 1) Upstream tarball contains .dlls that were not rebuilt from source
> > contained in the package.
> Yeah, thats a huge freaking no-no. That alone should invalidate the
> package for Fedora inclusion.
> > 2) Look through the installed .dlls for any that have the same name as
> > system .dlls or are suspiciously out of place (Package is myDiary and
> > contains mysql.dll, sqlite.dll, and gtk-sharp.dll)
> Yeah. It is worth noting that banshee seems to be doing this:
> /usr/lib/banshee/hal-sharp.dll
> But I don't see anything else using mono(hal-sharp).
> > 3) Source directories look odd:
> >   src/
> >   data/
> >   libs/
> >     gtk-sharp/
> >     atk-sharp/
> > 
> > Anything else?
> Yeah, not that I can think of.
> Mmmm, this gives a new meaning to DLL hell. Thoughts?

Give me back my Linux :-)

My current gut feeling is that all EXE and DLLs belong in %{_libdir}
rather than /usr/lib.  DLLs that are meant to be used only as part of a
single package belong with the EXE.  The EXE + DLLs go in
%{_libdir}/[PKGNAME].  Other DLLs (I'm assuming all other dlls are meant
to be used publically) belong in %{_libdir}/mono/ as part of the GAC.
This seems reviewable and hopefully does not require too much work to
make upstream packages conform.

Reviewing packages for suspect DLLs is going to be hard.  Eventually we
might be able to compile a list of known dlls that we have on the system
and so shouldn't be included in a package but it's going to be an uphill
battle as new libraries (and new versions of libraries) are created.
Convincing the mono-project that their recommendation has security
implications and they should consider withdrawing it may help.

-------------- 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/a6271471/attachment.sig>

More information about the Fedora-packaging mailing list