Mono Conventions Version: 0.2.1 (DEPRECATED! Superceded by the CLI Policy at

Conventions for packaging Mono/.NET applications/libraries for Debian GNU/Linux.

.NET Framework issues:

Note that there are no c-sharp-compiler alternatives yet, it is not clear whether we will create the c-sharp-compiler alternative entry. (Portable .NET is already debian and must be integrated soon)

Applications package issues... Possible cases:

General Naming:

* The official name of the Mono Project is: Mono, mono

or mono. To keep it unified (more transperant to the user) it should be always called "Mono", not MONO, not mono, not mono:: even no mixing with .NET in it. The explanation of Mono goes into the package long description.

Library Package Naming:

Currently, the mono base packages are named after their original naming scheme introduced a while ago. It is possible that they will be splitted into many packages like libi18n-west-cil.

THE PLAN (FHS conform packaging)

We create the directory /usr/share/dotnet (not in /usr/lib since all of this is arch-independent, interpreted code). In this "dot-net area", we create:

THE PLAN II (program invocation)

Why all this? First, to have reliable file locations. Second, to create a good generic application invocation tool and move non-native executable files out of /usr/bin. Shell wrappers for each application are the simplest and quite acceptable way. For those who are lazy to write them, I suggest an allround-program that looks for the right exe binary to start. We store it as /usr/bin/cli-wrapper. The application package would install a symlink cli-wrapper -> /usr/bin/program-name (without .exe!). The cli-wrapper is in the mono-common package and part of the cli-virtual-machine. What would the wrapper do on start? It checks argv["0"] (which is "mcs", for example). It looks for /usr/bin/mcs-exe (and executes it if found), then for /usr/share/dotnet/bin/mcs.exe, then for /usr/share/dotnet/bin/mcs/mcs.exe. The last one is a directory symlink, pointing to ../mono/1.0, so the wrapper finaly runs /usr/share/dotnet/mono/1.0/mcs.exe. These all is especially useful if the application has additional assemblies in its startup directory, or uses its own binary location to resolve other settings, like the default set of assemblies in the case of mcs.

THE PLAN III (managed package dependencies)

If you already got the idea how shared library on Debian are packaged, you almost know how the DLL assemblies are dealt with. There is one utility that creates a certain file with library name and version/compatibility data and the suggested dependency string. So every package providing libraries (?DLLs) installs a such config file (/var/lib/dpkg/info/*.netlibs). The dh_makenetlibs utility creates such files and installs them into the package directories. See manpages for (important) details.

The application packages working with the libraries use another tool to scan all binaries for references to ?DLLs and resolve them using the .netlibs files (see above), then the calculated dependency data is merged, filtered as needed and written to debian/package.substvars. You can insert it into the control files by using the ${net:Depends} variable. Note that there are few options controling the version detection behaviour and the package name filter (needed for packages with both native libs and cil assemblies, see libgnome-cil for example)

In order to use the dh_* tools, you will need mono-utils (>= 1.0).