[Fedora-packaging] Mono Packaging Issues

[Tom 'spot' Callaway]

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.

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

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). 

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)?

> 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?
2. Are the EXEs used like binaries? (They certainly seem to be)
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)
4. How much will mono (and its app) go nuts if we move the DLLs to
to /usr/share ?
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?

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.

>  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".

> 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:
> PKGNAME/
>   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?

~spot
-- 
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!