[Mono-list] Mono 2.6 for Ubuntu

[Jonathan Pryor]

On Tue, 2010-01-12 at 20:03 +0000, James Mansion wrote:
> You have to make the installation effectively self-contained. Everything 
> you say would apply to Java too - but there's just two files for that - 
> a .bin and a .rpm.

Right, but there's one crucial difference between Java and Mono.  Mono
wraps native libraries; Java doesn't.

For examle, libwnck?  Exposed by wnck-sharp, not available in Java.  
GTK+?  Exposed by Gtk#, not available in Java.  FreeType?  Ditto.
Gnome?  Ditto.

The short of it is that Mono directly and indirectly wraps lots of
native libraries in ways that Java does not.

As a consequence, a "self-contained" install would require bundling all
of these dependencies -- a completely separate freetype, GTK+, gnome,
etc., etc.  It would be *huge*.

Which is why the original "self-contained" installer wasn't: it relied
on the system GTK+, system freetype, etc.  This shows up lots of bugs as
people would try to install it onto GTK+ 2.2 systems (sufficiently old
that you don't want to go there), and people would be shocked --
shocked, I tell you! -- that Gtk# apps didn't work there.

I believe there were also LD_LIBRARY_PATH issues, where people would
often not have their environment properly sourced, leading to
"mis-matched" libraries being loaded into the process.  This leads to no
end of madness as well.

So, can it be done?  Sure.  Is it a good idea?  After years of trying,
we decided that it wasn't worth doing.  (But if you'd like to try,
please feel free to...)

> > So, in short, universal binaries are not all they're cracked up to be 
> > due to issues with maintaining a stable ABI and API, and integrating 
> > with the system, including integrating with a potential packaged 
> > installation of Mono that may be older (parallel Mono environments 
> > done incorrectly are a huge hassle). As an aside, they would also 
> > force Mono out of the free repositories into non-free repositories for 
> > distros which have strict from-source policies, and we don't want to 
> > add more fuel to *that* fire.
> 
> Why do you need to 'integrate with' a downlevel packaged installation?

Again, we 'integrate with' system-provided libraries, and it wouldn't
surprise me if e.g. Clipboard format of something generated by GTK+
changed between GTK+ versions, so it's conceivable that copy&paste
between a "self-contained Gtk# app" and a system-provided GTK+ app might
break in unpredictable ways.  (Mixing versions of libraries does things
like that.)  It's not for the faint of heart.
  
> And why care about the rest of it?  Novell would be in the same boat as 
> Sun:

As mentioned above, Sun isn't in this boat because their "pure Java"
initatives makes such native library wrapping verboten (or at least very
rare).  They don't depend on all these native libraries, not in the same
way that Mono does.

 - Jon