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 Acrobat. Removing distro-provided Java bits is the first thing I do after installation. James _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
