Packaging Mono 2.4 for Debian

Open Issues

None, Mono 2.4+dfsg-1 was uploaded to Debian/Experimental

Resolved Issues


Mono 2.0 now contains a relicensed version of JSON.NET, as the changelog shows:

2008-05-20  Jb Evain  <>
*.cs: all files from JSon.NET are now re-licensed under the
MIT/X11 license, thanks to his author James Newton-King
for relicensing them.

This would be just fine if James Newton-King would be the only copyright holder, source says though:

grep "Copyright" -r ./mcs/class/System.Web.Extensions/System.Web.Script.Serialization/JSON/ | cut -f2 -d ':' | sort | uniq
// Copyright (c) 2007 James Newton-King
// Copyright 2007 Konstantin Triger <>

Konstantin Triger is also a copyright holder and I can't verify that he also agreed on the relicensing. This issue will be brought to attention on the mono-packagers-list mailing list. So for now we can't include this part yet till this is resolved.

At quick interview of Jb Evain shows that Konstantin Triger wasn't explicitly asked if he agrees on relicensing:

13:34:33 <meebey> jb: hiya, during Mono 2.0 packaging I have a question popping up. Did you ask Konstantin Triger if he agrees on relicensing his code? (part of Mono's JSON.NET version)
13:34:51 <jb> yeah
13:34:56 <jb> well, it's not Konstantin
13:35:10 <jb> Konstantin used to work at Mainsoft and worked on that
13:35:18 <meebey> James Newton-King is not the only copyright holder
13:35:21 <jb> and his contributions are licensed under the mit/x11
13:35:40 <meebey> jb: the old copyright file didnt say that ;)
13:35:43 <meebey> err source
13:35:51 <meebey> it was Creative Commons
13:36:04 <meebey> so are you him or how do you know? :-P
13:36:35 <jb> I think it's a policy we have, every change to the class lib is licensed under the mit/x11
13:36:54 <jb> but I may be wrong, am not qualified to discuss such things :)
13:37:26 <jb> bbl
13:37:30 <meebey> thats not verifiable
13:37:38 <meebey> I will bring this up on mono-packagers-list

Konstantin Triger agreed to re-license the code:

From: "Konstantin Triger" <>
To: "Andrew Jorgensen" <>
Subject: Re: [mono-packagers] Re-Licensing of Mono's JSON.NET code in Mono 2.0
Date: Tue, 7 Oct 2008 10:22:27 +0200
Yes, feel free to relicense.


The mono-cairo.pc file is part of libmono-cairo1.0-cil and links of course with the CLI 1.0 version of Mono.Cairo. mono-cairo.pc needs to be moved to libmono-cairo2.0-cil and changed to use the 2.0 version.

bad /usr/bin/mod

Experimental Buildds Fail Using Mono 2.0

The following packages have unmet dependencies:
  cli-common-dev: Depends: mono-utils but it is not going to be installed or
  libmono-corlib1.0-cil: Depends: mono-jit (< 1.9.2) but 2.0.1-1 is to be installed
  libmono-corlib2.0-cil: Depends: mono-jit (< 1.9.2) but 2.0.1-1 is to be installed
  libmono-system-web1.0-cil: Depends: mono-jit (< 1.9.2) but 2.0.1-1 is to be installed
  libmono-system-web2.0-cil: Depends: mono-jit (< 1.9.2) but 2.0.1-1 is to be installed
  libmono-system1.0-cil: Depends: mono-jit (< 1.9.2) but 2.0.1-1 is to be installed
  mono-runtime: Depends: mono-jit (= 1.9.1+dfsg-5) but 2.0.1-1 is to be installed
                Depends: mono-gac (= 1.9.1+dfsg-5) but 2.0.1-1 is to be installed
E: Broken packages

22:56 <meebey> Package: mono-utils
22:56 <meebey> Depends: libc6 (>= 2.7-1), libglib2.0-0 (>= 2.16.0), libmono0 (>= 1.9.1), libmono0 (<< 1.9.2), libmono-corlib1.0-cil
22:56 <meebey> that one is clear

22:58 <meebey> Package: cli-common-dev
22:59 <meebey> Depends: debhelper (>= 7.0.8), perl-modules, mono-utils | cil-disassembler, mono-1.0-devel | strong-name-tool, libxml-dom-perl
22:59 <meebey> mono-1.0-devel I bet does it
22:59 <meebey> mono-utils (>= 2.0), mono-devel (>= 2.0)

Possible Workaround

23:38 <MoDaX> meebey: prepend the following in this order to mono-devel build depends
23:38 <MoDaX> meebey: libmono-corlib1.0-cil (>= 2.0), mono-runtime (>= 2.0), libmono-system1.0-cil (>= 2.0), libmono-system-web1.0-cil (>= 2.0), libmono-system-web2.0-cil (>= 2.0)
23:38 <MoDaX> s/build depends/depends/
23:38 <MoDaX> meebey: libmono-corlib1.0-cil (>= 2.0), mono-runtime (>= 2.0), libmono-system1.0-cil (>= 2.0), libmono-system-web1.0-cil (>= 2.0), libmono-system-web2.0-cil (>= 2.0)
23:41 <MoDaX> meebey: and order IS important

00:51 <MoDaX> meebey: sbuild is even more picky than satisfydepends-experimental. that's how depends on mono-devel 2.0.1-1 should look like for it to be installable under sbuild:
mono-runtime (>= 2.0),
 libc6 (>= 2.7-1) | libc6.1 (>= 2.7-1) | libc0.1 (>= 2.7-1),
 libglib2.0-0 (>= 2.16.0),
 libmono-corlib1.0-cil (>= 2.0),
 libmono-corlib2.0-cil (>= 2.0),
 libmono-system1.0-cil (>= 2.0),
 libmono-data-tds1.0-cil (>= 2.0),
 libmono-data-tds2.0-cil (>= 2.0),
 libmono-getoptions1.0-cil (>= 1.0),
 libmono-relaxng1.0-cil (>= 1.9),
 libmono-security1.0-cil (>= 2.0),
 libmono-system-data1.0-cil (>= 1.2.6),
 libmono-system-web1.0-cil (>= 2.0),
 libmono-system-web2.0-cil (>= 2.0),
 libmono-system-runtime1.0-cil (>= 2.0),
 libmono1.0-cil (>= 2.0),
 mono-2.0-devel (= 2.0.1-1),
 mono-gac (= 2.0.1-1)

Long Term Solution?

23:32 <meebey> directhex: mono-devel could dep on mono-libraries for example
23:33 <meebey> the tradeoff is lots of packages being pulled in
23:33 <meebey> thats the main reason we didnt go with it
23:33 <meebey> yet
23:33 <meebey> directhex: e.g. mono-devel >= 2.0, but libmono-something2.0-cil
23:33 <meebey> directhex: so we depend on concrete ABIs
23:33 <meebey> for the libs
23:34 <meebey> in the build-deps
23:34 <meebey> which is kinda destroying the "default target" goal
23:35 <meebey> mono-libraries -> mono-2.0-libraries -> libmono*2.0-cil
23:35 <meebey> mono-1.0-libraries -> libmono*1.0-cil
23:35 <meebey> mono-devel -> mono-librariey
23:35 <meebey> mono-2.0-devel -> mono-2.0-libraries
23:35 <meebey> mono-1.0-devel -> mono-1.0-libraries


Mono.Cecil.dll and cecil.pc are currently part of libmono1.0-cil and needs to be moved into a different package. The mono build system needs to be tweaked to create a 2.0 build of Mono.Cecil as it's currently only 1.0. What makes it more complicated is the fact that there are 2 API versions of cecil around: Mono.Cecil 0.6.8 from the mono source package and Mono.Cecil 0.5 from the mono-cecil source package. They _must_ not conflict! Solution: cecil is now build against CLI 2.0 and shipped in the libmono-cecil-private-cil package.

libmono-system2.0-cil binary deps

This package has a binary dep on libmono0 which should be avoided for space saving reasons. The class System.IO.Compression.?DeflateStream and System.IO.?SerialPorts.?SerialPortStream P/Invoke which is part of the libmono0 package. Should we split that library out into own package or can we override the depedency to Suggests or Recommends? Solution: runtime helper libs were moved from libmono0 to mono-runtime togehter with mono-common and mono-jit.