[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]


Debian CLI Policy
Chapter 3 - Packaging Policy


This section describes the additions to the Debian Policy that are required for CLI packages.


3.1 General Packaging


3.1.1 Architecture

For packages that consist of 100% managed code, "Architecture: all" must be chosen in debian/control.

Packages containing a mix of managed and native code must be "Architecure: any" or depending on the specific package a more restricted set of architectures is valid.


3.1.2 File Locations

The package's applications, libraries and meta-data must be installed into /usr/lib/upstream_package_name.

Libraries that will be installed into the GAC must be installed into /usr/lib/cli/assembly_name-X.Y (for more details about the X.Y version see GAC versioning). assembly_name is the assembly name without the file extension (.dll). The commonly seen /usr/lib/mono/upstream_package_name path should only be used for Mono project packages.

Example path for the log4net package:

     /usr/lib/cli/log4net-1.2

Never install native "glue" libraries into /usr/lib, instead install them at /usr/lib/cli/assembly_name-X.Y. When moving libraries update the references to the new location using a DLL Map. See the Mono DLL maps section for an example.

The only exception here is for native libraries that are of wider use; can be used other packages. Native libraries should be packaged according to the Library Packaging Guide in a Debian Policy conformant way.

You must not install application files (.exe) directly into /usr/bin. Instead create a wrapper script into /usr/bin to allow them to be run without path and the .exe suffix.


3.1.3 File Permissions

Source code files (*.cs, *.vb, *.boo, etc.) should be non-executable.

Library files (*.dll) should be non-executable.

Debug symbol files (*.mdb) should be non-executable.

Assembly config files (*.config) should be non-executable.

Application files (*.exe) must have the executable flag (+x) set to enable compatiblity with direct invokation as ./foo.exe using Linux's BINFMT support.

To ensure that all files have correct permissions, you should use Debhelper's /usr/bin/dh combined with cli.make. Otherwise you should add dh_clifixperms after dh_fixperms in the binary-* targets of debian/rules.


3.1.4 Build Dependencies

At a minimum, CLI packages should Build-Depends on cli-common-dev (>= 0.7) and the appropriate CLI compiler or CLI SDK package.

Current CLI compilers in Debian:

Current CLI SDKs in Debian:

Software that uses Mono via the C interface library (libmono.so) or requires the /usr/lib/pkgconfig/mono.pc file must Build-Depends on libmono-dev (>= 1.0)

Note that there are architectures for which no CLR is available and thus you may have to restrict the Build-Depends for your package to the architectures available.

If your package is Architecture: all, you should specify this as Build-Depends-Indep. Never put debhelper, cdbs, dpatch and quilt into Build-Depends-Indep. See the Debian Policy Manual for more information on this.


3.2 GAC Library Packaging

Libraries that are installed into the GAC should provide decent ABI stability and be useful for other packages. Otherwise, they should remain private to the package.


3.2.1 Naming & Versioning

Libraries that are installed into the GAC must be strong-named, i.e. signed.

Libraries must to be installed into the GAC at package install time (postinst) which is provided by the dh_installcligac tool of the cli-common-dev package.

Each of the libraries in the GAC has an assembly version number that consists of 4 parts (major, minor, build and revision number). When loading libraries from the GAC all 4 parts and the public signing key fingerprint must match.

It is general practice and recommended by Microsoft that a library is ABI compatible when only the build and revision number change and the major and minor number stay the same.

The library package name must be prefixed with lib.

To reflect the ABI stability and prevent breakages when a ABI-incompatible version is released, a similar solution for native library packages is used. The major and minor number must mirror the SONAME version and the resulting package name should be libfooX.Y-cil, where X is the major and Y the minor number of the assembly version.

One notable exception for this naming are assemblies that end on a number (Mono.C5 for example). In this case the package should be named libfoo123-X.Y-cil (i.e. libmono-c5-0.5-cil) to improve the readability.

The -cil suffix is chosen to prevent confusion with native library package names. Never use "sharp" in the package name as it does not represent the language, and a CLI library can be used with all CLI implemented / enabled languages such as C#, IronPython, IronRuby, Boo, Nemerle, J#, VB.NET (full list).

Unnecessary package renames should be avoided. Existing package names that do not follow this policy should not be renamed until the next incompatible ABI change, at which point the new naming scheme should be used.

If the upstream software does not use major and minor number to reflect ABI stability or breaks ABI with a change in build or revision, the package must be renamed to either libfooA.B.C-cil or libfooA.B.C.D-cil (where A, B, C, D are the complete assembly version numbers), depending at which point (major or minor) the breakage occurred. All Policy Files must be dropped at this stage until a new major or minor version is released.

The upstream software may use wildcards in the assembly versions (1.2.* for example) which are filled by the compiler with a random value. You must replace these wildcards with 0 (1.2.0.0 in the example) to make it possible to use Policy Files and make predictable version numbers.

More than one library can be installed in one package but it is required that they must all have the same assembly version and belong together.


3.2.2 Policy Files

As explained above a exact match of the version number is required to load a library from the GAC. To override this behaviour and make different versions of ABI-compatible library packages really ABI-compatible you have to use Policy Files. These files have to be named policy.X.Y.foo.dll (where X and Y are the major and minor number of the assembly it should be compatible with), it must be signed with the same signing key as the original assembly and it must be installed into the GAC. For information on how to create policy files look at the previous Policy Files link or at the example below.

Overriding the GAC policy should only be done when the different library versions are really ABI-compatible. This can be checked using mono-api-check of the mono-devel package. You must also raise the version in the clilibs control file to the minimum version when new interfaces/classes/methods were added.


3.2.3 clilibs Control File

The clilibs control file MUST be present in all GAC library packages. It can be created with the dh_makeclilibs helper script and has a format similar to the shlibs file created by dh_makeshlibs(1) and also has a similar use: it is used by dh_clideps helper script to find the correct dependencies.

You should always set the minimum required version of the library in the clilibs file.


3.2.4 pkg-config File

Many libraries deliver a .pc file for use by the pkg-config helper utility, which aids other libraries and applications to link against libraries.

All GAC library packages should have a pkg-config .pc file located in /usr/lib/pkgconfig. The filename must be identical to that shipped by upstream.


3.2.5 Signing

When installing libraries into the GAC signing is required. The signing key should be supplied by upstream. If upstream is not supplying the key then you must use the mono.snk key from the cli-common-dev package. This key must be used for all following versions of the library to maintain ABI compatbility.

Unnecessary ABI breakages should be avoided. Existing keys shipped by the source package should not be replaced (with mono.snk) until the next incompatible ABI change.


3.3 non-GAC Library Packaging

This includes libraries that are not ABI-stable, may be not strong-named and are usually in an early stage of development. They must not include a clilibs control file.


3.3.1 Naming

The package should be named libfoo-cil (without a version in the package name) and libraries should not be installed into the GAC but only into /usr/lib/upstream_package_name.

Applications using non-GAC libraries must copy the libraries they need into their own application directory. You can compare this with static linking of native libraries.


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]


Debian CLI Policy

Version 0.7

Mirco Bauer mailto:meebey@debian.org
Brandon Hale mailto:brandon@smarterits.com
Sebastian Dröge mailto:slomo@debian.org
Dylan R. E. Moonfire mailto:debian@mfgames.com