The-Source.com

It’s almost nostalgic to be posting so often about Mono, but hopefully the Gentle Reader finds this post worth his valuable time.

The Claim

One of the common claims of the Mono proponent is that distribution packagers are splitting Mono into ECMA and non-ECMA packages. Debian and/or Ubuntu are commonly held up as examples in this area.

This always seemed a questionable claim to me: for one thing, it’s not easy to determine exactly what bits go where, and to be frank who has the time to screw with that? Also, there are a host of technical considerations – what if they conflict somehow? Furthermore, how will users know which packages are “safe” or “unsafe”? And, as we have seen, all the Mono apps need “unsafe” stuff anyway – so why bother splitting things up?

Also, without being crass about things – I don’t think that most Mono proponents’ top priority is the safe/unsafe distinction. Generally, it seems to me, if you are supporting Mono, you are in for a penny in for a pound and not too concerned over nuance unless forced to discuss it by raging freetard zealots such as myself. We all have our special roles to play.

Enough setup — I thought I might check out a package and see if we can accept or reject the claim that some distribution packagers are splitting Mono into ECMA and non-ECMA pacakages.

The Exam

Now we do have some Debian packages like libmono-system-data2.0-cil and libmono-winforms2.0-cil, so a casual glance might suggest that there is some ECMA/non-ECMA division going on.

On that note, I took mscorlib.dll from the Debian package libmono-corlib2.0-cil (2.6.7-3). This is the “Core Library of Mono for CLI 2.0″, and as far as I can determine absolutely required for any Mono whatsoever on your system.

[jason@apollo 2.0]$ egrep -I -a -o 'S.y.s.t.e.m.............................' mscorlib.dll | sort | uniq
SystemSystem.Data1S
System Operators/BUI
System, Version=2.0.
System.Attribute.}e
System.Byte.!Value t
System.Char
           utf32QTh
System.Core, Version
System.Data, Version
System.Data.OleDb.Ol
System.Data.SqlClien
System.DateTimefile
System.DecimalCInval
System.Decimal.Parse
System.Design, Versi
System.Diagnostics.E
System.Diagnostics.P
System.DirectoryServ
System.DoubleUDouble
System.Drawing!Syste
System.Drawing, Vers
System.Drawing.Desig
System.Drawing.Print
System.Guid.CompareT
System.Int16ArraySu
System.Int16;Value i
System.Int32s%Value
System.Int64qInput s
System.Messaging, Ve
System.Messaging.Mes
System.Net.DnsPermis
System.Net.SocketPer
System.Net.WebPermis
System.NonSerialized
System.Reflection.As
System.Resources.Res
System.Resources.Run
System.Runtime.Compi
System.Runtime.Inter
System.RuntimeType)S
System.SByte.7Value
System.Security, Ver
System.Security.Cryp
System.Security.Perm
System.Security.Poli
System.Security.Supp
System.SerializableA
System.ServiceProces
System.Single.9Value
System.Text.CP5CodeP
System.Text.ENCCEnco
System.Type are not
System.UInt16.5Value
System.UInt32.Negat
System.UInt64.7Value
System.Web, Version=
System.Windows.Forms

What’s this!? System.Data? System.Drawing? System.Windows.Forms!?!

The Verification

So, it appears that there are non-ECMA bits even in the “most basic” Mono library. At this point, I was pretty sure we could reject the claim.

However, even in my freetarded factfinding frenzy I wanted to be sure, so I did something absolutely insane: I asked Jo Shields about it. (In case you don’t know, Mr. Shields packages Mono for Debian and Ubuntu.)

Mr. Shields was kind enough to respond, and here’s the summarized deal:

1. ECMA/non-ECMA is not a consideration in packaging Mono.
2. No distribution ships Mono with ECMA-only components.
3. It is not possible to do so without “deep surgery”.
4. Splitting along ECMA/non-ECMA lines is not a priority.

So, we can reject the claim that distribution packagers are splitting Mono into ECMA/non-ECMA components.

The Thank You

My sincere thanks to Jo for taking the time and effort to reply.

The Unredacted Email

At Mr. Shield’s suggestion, here is the unredacted email (which contains my original email), so everyone can get context and judge for themselves. I suggest reading it if you are interested in more about the packaging details behind Mono.

On Mon, 2010-12-13 at 14:43 +0900, Jason Melton wrote:
> Jo,
>
> Your favorite zealot here. I'd like to ask some questions on a Mono
> Packaging issue before I write a post about it. I want to do this so I
> have "asked someone in the know" as well as offer you an opportunity
> to respond if you desire in the post itself.
>
> If you want me to F off and not bother you again, I'll respect that, of course.

For actually asking me the question, I'm happy to answer fully. It's
more than Roy's ever done.

> Anyway, on to the questions:
>
> 1. Is the Debian Mono packaging split into ECMA / non-ECMA components?

It's split into a hundred odd packages, but no, ECMA/non-ECMA isn't a
consideration - the only consideration is minimizing dependency chains
whilst retaining usefulness (and reducing circular dependencies), and
grouping related items. As an example, a minimal install (mono-runtime
plus its dependencies) pulls in four library packages, containing the
following assemblies:

libmono-corlib2.0-cil:
mscorlib.dll

libmono-posix2.0-cil:
Mono.Posix.dll

libmono-security2.0-cil:
Mono.Security.dll

libmono-system2.0-cil:
System.Configuration.dll
CustomMarshalers.dll
System.Management.dll
System.Transactions.dll
System.Drawing.dll
System.Xml.Linq.dll
System.Xml.dll
System.Core.dll
System.Security.dll
System.dll
System.ServiceProcess.dll
System.Configuration.Install.dll

So these assemblies are the unavoidable minimums installed on a current
system (Ubuntu Maverick). But they cover most situations outside
compilation, where we pull in the kitchen sink in order to provide
simpler Build-Depends lines. And if you aren't aware, note that assembly
names do not necessarily match the namespaces provided therein. Whilst
it would be possible to chop things out of libmono-system2.0-cil to make
a pure-er (although likely not completely pure) minimal system, I think
the benefits to our users would be minimal, and the cost in terms of
awkwardness on upgrades high.

> 2. If there is a split is it an official policy?

See above

> 3. If there is a split is it comprehensive/complete or in
> progress/trying-our-best-but-not-100%-just-yet-for-whatever-reason?

See above-er

> 4. How could a non-packager determine which bits should go where and
> verify that the packaging is correct?

As I said, the concern is really just over minimizing chains of
dependencies, so what makes us sit up and make changes is cases where
pulling in an extra library leads to pulling in several more - that's a
scenario we want to avoid. As an example, when attempting to attack
Banshee with a scalpel (the changes noted in the current Natty package),
we found two instances where depending on a single library would pull in
buckets more random stuff. Using System.Data pulled in the
libmono-system-data2.0-cil package - but one of the rarely-used
assemblies in that package pulled in libmono-wcf3.0-cil and all ITS
dependencies, bloating things up. Our solution was to split the "bad"
assembly into a new package (will be in Mono 2.6.7-4), Banshee
upstream's solution was to drop System.Data entirely (already in the git
snapshot in Natty).

The other example is the Youtube extension using the google-gdata
packages (which contain about 14 assemblies for managing various Google
web services), one of which uses System.Web. Banshee upstream provided
us with a minimal patch to remove that dependency, by copying a little
of Mono's source code (GData upstream already did this to provide
missing namespaces on the Microsoft.NET Compact Framework, so we just
added one or two missing methods and removed the ifdef).
libmono-system-web2.0-cil suffers from a similar, but sadly unavoidable,
chain of dependencies which we sought to cut off. Due to obtuse Windows
line-ending issues, showing you the patch wouldn't be meaningful or
interesting.

So now Banshee's dependency list isn't much different from Tomboy or
gBrainy. See http://people.ubuntu.com/~hyperair/banshee-dep.png for the
visual version of the above.

> 5. When I examine mscorlib.dll I see references to non-ECMA components
> such as System.Data and System.Drawing. [1] Does this mean that
> mscorlib.dll (from the Debian package
> libmono-corlib2.0-cil_2.6.7-3_all.deb) contains non-ECMA components?

Congratulations for being the first Mono critic (AFAIK) to notice this.
I was going to blog on this topic at some point, once finishing my
current secret Project Marmoset.

You're correct. ECMA 335 defines HOLY SHIT. They updated it to .NET 4.0!
That's news to me that is! You'd have thought Miguel would have blogged
about it. Damn, now I need to restart Project Marmoset.

Sorry. Anyway, the currently MCP'd version of ECMA 335 (4th edition,
2006) defines 331 different classes, with 617 properties and 2097
methods, split across System.dll, mscorlib.dll, System.Xml.dll, and
System.Threading.Parallel.dll. Not every namespace in those assemblies
is defined in the ECMA spec - the spec covers individual methods and
properties on individual objects, each one needing vetting one by one by
the standards committee.

So the current (okay, not current, I'm on 2.6.7 here) Mono
implementations of the named libraries contain:

mscorlib.dll: 1085 classes, 13438 methods, 3213 properties.
System.dll: 822 classes, 8644 methods, 3109 properties.
System.Xml.dll: 240 classes, 5384 methods, 2158 proprties.

I should stress that I'm relying on grep for numbers here, so I don't
know how much autogenerated noise is included in the monodis output.
Probably plenty, but even with that it's clear that the implemented
methods & properties exceed the ECMA methods and properties. And no, I
don't know where System.Threading.Parallel.dll is either. And yes, I
know that the Community Promise needs everything in the spec to be
implemented. Go figure.

FYI, ECMA 335 5th edition increases the number of ratified classes from
331 to 374, properties from 617 to 651, and methods from 2097 to 2319.

> Obviously, I think that the package contains non-ECMA bits and want to
> point this out as a counter argument to those who say that Mono is
> split into "safe"/"unsafe" bits by distro packagers and often use
> Debian/Ubuntu as an example.

As far as I can tell, most people consider some technologies
more dubious than others - System.Windows.Forms or System.Data is
hairy, whereas a non-spec method on the String class doesn't make
everybody leap in fear. Whether that's naive is the topic for a
different flame war, I suspect.

So it's true that we have distinct packages for the "scary" bits like
System.Data versus "less scary" stuff like mscorlib.dll, but it is
absolutely true to say that no distribution ships a Mono framework with
ECMA-only components, and it's not possible to do so without deep
surgery on the class library, requiring a lot of man hours. Which is
time Miguel would rather get his guys to invest in MonoDroid or
MonoTouch. Completely hypothetically, I think using the monolinker tool
from MonoTouch (which creates custom minimized versions of the class
libraries on a per-app basis) to turn a "full" Mono into an ECMA-only
Mono would be a faster route to the stated goal, but I have no idea
what would run, and no idea whether monolinker would be prepared to
chop off that much stuff. Would sure be interesting though, wouldn't it?

> I'm trying to get your input so I can be sure of my facts and to
> present "the other side". It's the first time I've tried such a thing,
> so your response is much appreciated. If it helps I can send you a
> copy before I post it so you know I don't quote you out of context or
> anything shady like that.

Whilst I think we disagree pretty strongly about comparative risk, your
dedication towards accuracy in this matter is appreciated. I don't
think anything I've written here is incorrect, so I don't want you to
feel you need to provide me with your intended blog post in advance. If
I'm wrong, I'm sure corrections will appear in comments. And wrong or
right, people like gnufreex will call me Satan, so there's not much
advantage to advance copy.

I think the question of context would be best served by providing
readers access to all emails unredacted, so they (pro or anti Mono) can
form their own opinions on context.

> [1] Basically: egrep -I -a -o 'S.y.s.t.e.m....[lots of dots]...' mscorlib.dll

Try using "monodis", which decompiles .NET code to MSIL (or whatever
they're calling it today). A cursory examination suggests there are
mentions, but not dependencies. Stuff like InternalsVisibleTo, at a
guess, which gives those assemblies access to non-public content inside
mscorlib. I can't read MSIL, so I'm largely guessing. If there were a
true dependency, the packaging would pick up on it.