The Mono Debian Plan,

written by Mirco Bauer <meebey@meebey.net>

Why this plan, whats wrong?

The packaging in debian of the mono suite has severals problems since the beginning of the packaging for the official debian distribution. Mainly it started with FHS problems when Mono shipped the .NET assemblies in $prefix/bin ('''.dll and '''.exe). The Debian Mono Group wrote a draft how we could address this problem. Later we ended up with having "Mono Conventions", within these conventions the main part was to integrate .NET applications flexible in the debian system and having an unified directory structure.

Today we have some serious problems with the "/usr/share/dotnet/" solution. Miguel de Icaza gave a good explanation where it breaks things.

Problems:

  1. All .NET applications needs to be patched in order to become conform with the ?MonoConvetions, with the base packages this was not a big issues, but when more and more .NET applications arrive in debian it will become a general "PITA".

  2. Integration with different runtimes is not that easy as we thought when we wrote the MonoConventions, we tried to allow running any .NET program with any .NET runtime. This in practice seems to be not possible without major changes in the programs, and even mostly impossible duo strict dependencies on mono technologies/libraries. Also sharing class libraries is not possible between runtimes, like pnet using files of the mono classlib. This fails because the classlib may call code within the mono implementation which does not exist in others.

  3. AOT (Ahead-Of-Time) feature of Mono can't work when it lives in /usr/share, it's a read-only area (by FHS).

  4. .NET is not that arch independent as we thought. The bytecode is of course itself arch-indep but when it comes to programs and libraries, those may have "define code" which depends on the architecture when it's compiled and will cause problems when used on other architectures. Currently this is not the case with Mono, but this may change with time. Xsharp is a library with does this already. Means a typical .NET application should be seen as arch-depended in the first place, in as per application basis they could be packaged as arch-indep software.

Summary:

Packaging .NET applications for Debian is pain and breaks very fast software and results in packages which do not work as expected. This also has influence for upstream authors as they see the software is changed in major ways and dislike this (who would not if someone else changes the structure of the program), when the application has problems/bugs the author may first think its related to the packaging (and this even could be often for real the case).

The Plan:

Firstly I have to say that there is no chance now for Mono to go into debian/sarge. Why? In this state (with all the problems) the packages will not do any good when it gets frozen in Sarge, it would cause huge problems later when the next stable release (etch) will follow.

We drop the current MonoConventions and start with a .NET policy draft for Debian, with general conditions, not as aggressive as the MonoConventions does. It will define mainly: runtime integration (if possible at all), package naming, library handling and dependency tracking.

Next, we will package Mono 1.1.x, it solves the FHS problems. Beginning with Mono 1.1.3, all the assemblies are located in $prefix/lib/mono/VERSION (1.0 uses $prefix/bin). Other Mono applications follow this new structure, means other applications are also fine with the FHS. Mono 1.1.3 ships now in one tarball (containing the whole source), this makes the management of automated building a lot easier.

Mono 1.1 based on the .NET policy will be uploaded to experimental. When it's well tested with several applications, we will upload it to sid.

We will maintain and provide Debian packages for Sarge and offer them via go-mono.org, this should allow all Debian Sarge users to get good Mono packages for debian.

Summary:

Thanks: