The Mono Debian Plan,

written by Mirco Bauer <>

Why this plan, what's 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.


  1. All .NET applications needs to be patched in order to become conform with the MonoConventions, 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).

    1. An explanation of how this is that different from Python's py[ co ] and Plt scheme's zo files and how they are handled at install time would be nice.

  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. 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. In most cases this can be solved by checking to see if the application has any pinvoke code by doing a quick grep for "?DllImport" or if the application includes code like a traditional C or C++ libraries to function as glue libraries to things inaccasable to mono directly.

    1. (The old ?XSharp library comment was useless as it is pnet related not Mono since they have a better Managed.Windows.Forms that is arch independent )

There are also other things that Mono packagers experienced with few upstream developers ("social problems", unwillingness to support installation in ANY different location than their default one).

Mono developer comment

Its usually not our own issue with not being easier to change from the default path, but that of people upstream of us as well (so place this does exist as well) with products we use to test and deploy with. Also some of code is in C# which doesn't remap well to other directories since mapping is not set at build time (since build time checks and changes are nasty with us as it breaks one of the main goals with wanting the apps to be free of those build time checks and machine specific constants) and their is no reliable way of checking a special diectory. We do support modifiy prefixes for most things to make it easier for Mac and Windows users however. The solution of us sharing with pnet in shared directory is very very nasty as we do not have a lot of people that care to run pnet to test as we don't want to containate our build eviroments with tools that remap our own.


Packaging .NET applications for Debian is painful 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 beeing pointed to the drawbacks of hardcoded paths), 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, meaning that 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, this should allow all Sarge users to get good Mono packages for Debian.

Summary and Status:

All tasks are completed!