Packaging Mono 2.4 for Debian
None, Mono 2.4+dfsg-1 was uploaded to Debian/Experimental
Mono 2.0 now contains a relicensed version of JSON.NET, as the changelog shows:
2008-05-20 Jb Evain <email@example.com> *.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 <firstname.lastname@example.org>
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" <email@example.com> To: "Andrew Jorgensen" <firstname.lastname@example.org> Cc: email@example.com 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. Kosta
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.
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 cil-disassembler 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)
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 libMonoPosixHelper.so 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.