[Mono-list] Mono 2.6 for Ubuntu

James Mansion james at mansionfamily.plus.com
Tue Jan 12 15:03:29 EST 2010

B.R. wrote:
> Universal binaries were provided at one point, in the form of an 
> "Universal Linux Installer." These were discontinued around Mono 
> 1.9.1, because they didn't work properly on most distros: components 
> that were relied on were not ABI-stable, installed binaries would stop 
> working because libs would change on the system, libs would be in the 
> wrong places without LD_LIBRARY_PATH being set, etc. In short, it was 
> one giant cockup for the most part, and was hence discontinued in 
> favor of letting distro packagers handle it themselves, seeing as in 
> almost every case, they know better.
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.

> 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?  
And why care about the rest of it?  Novell would be in the same boat as 
Sun: you can supply a standalone integrated (and controlled) universal 
bin, and let the packagers do what they can with the open source bits - 
and let the users choose.  I'd not expect the bin to live in an 
repository - just for a simple script to do the download to be the 
package for the bin: pretty much as it is with the Sun JVM and Adobe 

Removing distro-provided Java bits is the first thing I do after 


More information about the Mono-list mailing list