[Mono-list] Mono 2.6 for Ubuntu

B.R. severedcross at gmail.com
Mon Jan 11 16:21:23 EST 2010


On Mon, Jan 11, 2010 at 3:42 PM, James Mansion <james at mansionfamily.plus.com
> wrote:

> B.R. wrote:
>
>> It's not really up to Novell here, it's up to the Debian/Ubuntu
>> maintainers to decide when new versions get supported. Part of the reason
>> for this is that Debian, and by extension Ubuntu, have very specific
>> policies on how things should be packaged (the Debian Free Software
>> Guidelines are very strict, and the Mono project does violate them in a few
>> places), and Novell simply haven't the resources to invest in hiring someone
>> specifically to do Debian (and by extension Ubuntu) packaging, so it's left
>> up to the maintainers who do a pretty good job with the time and resources
>> they have. The reason binaries are shipped for Windows with every release is
>> because there's no package specification to follow, so the binary packages
>> are easy to build (build the libs, put them in the right places, package
>> them up in an installer and you're good to go).
>>
> I think that's a bit lame - it makes a big assumption about the mono team
> shipping a package for a start. Binary compatibility for apps (if not
> drivers) is at least passable with current Linux systems.  Why should it be
> hard to ship a universal binary when Adobe and Sun (in particular) have
> managed it for a long time?
>
> I can see that Novell need SLES to be the best platform for Mono for
> commercial, but I think it needs to be ubiquitous first and then given value
> add on the Novell product - and that means better support for other Linuxen,
> and OpenSolaris, and FreeBSD.
>
> James
>
> 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.

Another part of the problem is that Mono isn't just an app, it's an entire
framework. Lots of pieces to be updated, lots of packages to be built, lots
of packages to rebuild from source to make sure that they work with a newer
version, mondo amounts of regression testing to do. This is part of the
reason Mono on Ubuntu has traditionally been rather far behind: Mono is a
core framework (shipped on the LiveCD and all) and thus won't get SRUs
(stable release updates) except for edge cases (minor updates, etc.).

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.

--B.R.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20100111/0d2550ab/attachment.html 


More information about the Mono-list mailing list