Differences between revisions 17 and 18
Revision 17 as of 2008-11-12 15:17:18
Size: 16263
Editor: ?directhex
Comment:
Revision 18 as of 2008-11-12 15:20:07
Size: 16137
Editor: ?directhex
Comment:
Deletions are marked like this. Additions are marked like this.
Line 25: Line 25:
== Allright, just 10MB, that's all you got? == == Alright, just 10MB, that's all you got? ==
Line 47: Line 47:
Secondly, replace any dependencies on mono-mcs, mono-X-devel, mono-gac, and so on, with a simple new dependency: "mono-devel". mono-devel will pull in the default build version (mono-2.0-devel), and includes 'unversioned' scripts (more in the next section). If you still need to build 1.0 code for some reason, then depend on "mono-devel, mono-1.0-devel" to pull in the new version. Now our Cowbell looks like this: Secondly, replace any dependencies on mono-mcs, mono-X-devel, mono-gac, and so on, with a simple new dependency: "mono-devel". mono-devel will pull in the default build version (mono-2.0-devel), and includes 'unversioned' scripts (more in the next section). Now our Cowbell looks like this:

New Mono 2.0 Package Layout

Why?

Because a simple application like tomboy still needs 49.9MB, which is too much to be included in the default debian install for example http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;att=0;bug=484121 0.

Aren't the Mono packages very split already?

Yes they are but not enough to get small enough installs. This is caused by:

  • indirect native dependencies (e.g. sqlite, libgdiplus, gtk+, etc)
  • 2 different runtime profiles (1.0 vs 2.0)

So how to solve this mess?

With Lenny+1 (Squeeze) we will make the 1.0 runtime deprecated and compile all CLI libraries and CLI applications for only the 2.0 runtime. We will still ship the 1.0 runtime libs of Mono but they will only work for applications that do not require other Debian CLI library packages (such as GTK#).

Doesn't this require a transition?

Yes it does, all Debian CLI library and application packages need to be rebuild using gmcs instead of mcs (if they are not using gmcs by default already!). To get an idea of how many packages are built against the 1.0 runtime:

 apt-cache rdepends libmono-corlib1.0-cil | grep -v libmono- | grep -v mono- | wc -l 84 

So 84 binary packages are built using the 1.0 compiler (mcs) for targeting the 1.0 runtime. (btw libmono-* and mono-* packages don't count, as they will still be shipped for the 1.0 runtime for compatibility with external (as in non-debian) applications)

OK, so all this work for exactly what gain now?

As said a tomboy install needs 49.9MB of additional harddisk space when installed on a default debian/lenny system.

Tomboy is using the 2.0 runtime of Mono but uses libraries that was compiled for the 1.0 runtime and thus it pulls in 1.0 runtime libs + 2.0 runtime libs. If all libraries would use the 2.0 runtime it would reduce the tomboy install by over 10MB (and that just by recompiling the libs using gmcs).

Alright, just 10MB, that's all you got?

Nope, with this 1.0 -> 2.0 transition we will also split the Mono packages to further reduce dependency chains.Tomboy for example only use the Mono.Posix.dll library from the libmono2.0-cil package or the libmono0 which is only needed by C applications that do calls into Mono. So we would put the Mono.Posix library into an extra package as it's used almost by all Mono based GUI applications, this gives us 4.8MB back of the harddisk, and with libmono0 we get 2.3MB back.

So now we are at 10MB + 4.8MB + 2.3MB = 17.1MB

Tomboy itself is 10MB in size, this is mainly because it contains graphics with texts that need to be translated in many languages:

 du -sh /usr/share/gnome/help/tomboy
 5.7M    /usr/share/gnome/help/tomboy

Instructions for packagers

There are three things that need to be changed to take advantage of the changes above (and, indeed, to allow building of any packages after the transition takes place). For this, we'll look at a simple 1.0-based package: Cowbell.

Build-dep changes

Currently, the package has the following build dependencies

Build-Depends: debhelper (>= 5), cdbs, cli-common-dev (>= 0.4.4), mono-mcs (>= 1.0) | c-sharp-compiler, mono-1.0-devel, libmono-corlib1.0-cil, libmono-system1.0-cil, libmono-system-web1.0-cil, libtag1-dev (>= 1.3.0), libtagc0-dev (>= 1.3.0), libgtk2.0-cil (>= 2.6), libglib2.0-cil (>= 2.6), libglade2.0-cil (>= 2.6), pkg-config, intltool, xsltproc, docbook-xsl, docbook-xml (>= 4.4)

Firstly, replace all the 1.0 versions of libmono packages with 2.0 versions - pay extra close attention to non-obvious packages like sharpzip, whose version number isn't obviously 1.0/2.0

Secondly, replace any dependencies on mono-mcs, mono-X-devel, mono-gac, and so on, with a simple new dependency: "mono-devel". mono-devel will pull in the default build version (mono-2.0-devel), and includes 'unversioned' scripts (more in the next section). Now our Cowbell looks like this:

Build-Depends: debhelper (>= 5), cdbs, cli-common-dev (>= 0.4.4), mono-devel (>= 2.0), libmono-corlib2.0-cil, libmono-system2.0-cil, libmono-system-web2.0-cil, libtag1-dev (>= 1.3.0), libtagc0-dev (>= 1.3.0), libgtk2.0-cil (>= 2.6), libglib2.0-cil (>= 2.6), libglade2.0-cil (>= 2.6), pkg-config, intltool, xsltproc, docbook-xsl, docbook-xml (>= 4.4)

Patching the build system

Ideally, you should patch your application's build system to use unversioned tools - those included in the mono-devel package - which will be those from the default Mono runtime on the system. 'al' is an example here - instead of 'al' for 1.0 and 'al2' for 2.0, we have 'al1' for 1.0, 'al2' for 2.0, and 'al' for the system default.

The most important one to patch here is the compiler - you should alter your configure scripts to look for 'csc' instead of 'mcs' or 'gmcs' - csc will be the default compiler on the system, which currently means gmcs2.

In the case of Cowbell, it's a single entry in configure.in to update:

AC_PATH_PROG(CSC, mcs, no)
if test "x$CSC" = "xno" ; then
        AC_MSG_ERROR(['No c-sharp compiler found'])
fi

becomes:

AC_PATH_PROG(CSC, csc, no)
if test "x$CSC" = "xno" ; then
        AC_MSG_ERROR(['No c-sharp compiler found'])
fi

Obviously, autoconf is needed again here. And really, using a patchsys is better than editing files directly.

Testing, testing, testing!

Does it build?

directhex@despair:~$ dpkg-deb -I cowbell_0.2.7.1-2_amd64.deb | grep Depend
 Depends: libc6 (>= 2.2.5), libc6 (>= 2.7-1) | libc6.1 (>= 2.7-1) | libc0.1 (>= 2.7-1), libgcc1, libglade2.0-cil (>= 2.12.0-2ubuntu3), libglib2.0-0 (>= 2.16.0), libglib2.0-cil (>= 2.12.0-2ubuntu3), libgtk2.0-cil (>= 2.12.0-2ubuntu3), libmono-corlib2.0-cil (>= 1.2.2.1), libmono-system-web2.0-cil (>= 1.9.1), libmono-system2.0-cil (>= 2.0), libstdc++6 (>= 4.1.1-21), libtag1c2a (>= 1.4), libtagc0 (>= 1.4), mono-runtime (>= 1.1.8.1)

You bet! Sometimes your package might require some mild patching - for example, System.Web.Mail became System.Net.Mail in the 2.0 CLR. But as you can see from the five minute example above, the amount of work needed to migrate to the 2.0 runtime is in theory minimal.

Random IRC dumps

oftc/2008-08/#debian-mono.08.log:08-08-2008 10:57:18 > directhex: what is actually needed, other than a smarter mono-gac and changing deps in libs like gtk# from 1.0 to 1.0|2.0 ?
oftc/2008-08/#debian-mono.08.log-08-08-2008 10:57:49 < meebey!meebey@booster.qnetp.net: there are technical issues, dont remember them right now
oftc/2008-08/#debian-mono.08.log-08-08-2008 10:58:07 < meebey!meebey@booster.qnetp.net: I made a use-case some time ago when we talked about it, my conclusion was again: not possible
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:01:31 < meebey!meebey@booster.qnetp.net: oh yeah I partly remember
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:01:36 < meebey!meebey@booster.qnetp.net: a hack would have been
oftc/2008-08/#debian-mono.08.log:08-08-2008 11:02:05 < meebey!meebey@booster.qnetp.net: Depends: libmono-system1.0-cil | libmono-system2.0-cil for 1.0 CLI libs
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:02:12 < meebey!meebey@booster.qnetp.net: but
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:02:53 < meebey!meebey@booster.qnetp.net: lets say its a 2.0 lib and only 1.0 is installed
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:03:03 < meebey!meebey@booster.qnetp.net: the dependency is satisfied
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:03:07 < meebey!meebey@booster.qnetp.net: but will crash
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:03:27 > directhex: are 2.0 libs back-mappable, the way 1.0 libs are forward-mappable?
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:03:53 < meebey!meebey@booster.qnetp.net: nope
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:04:00 < meebey!meebey@booster.qnetp.net: 2.0 include features that 1.0 doesnt has
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:04:03 < meebey!meebey@booster.qnetp.net: like generics
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:04:04 > directhex: also, do you know which policy section is violated? reportbug wants a "must" or "required" directive
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:04:44 > directhex: so only make 1.0 libs 1|2? the apps themselves pull in things like corlib 1 or corlib 2 as needed, so it doesn't matter if you have gtk#, only corlib 2, then install a 1.0 app
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:04:51 < meebey!meebey@booster.qnetp.net: its a DFSG violation
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:05:00 < meebey!meebey@booster.qnetp.net: did you check the URL?
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:05:53 < meebey!meebey@booster.qnetp.net: directhex: you dont know which runtime and thus which runtime libs will be used up to the application start
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:06:08 < meebey!meebey@booster.qnetp.net: directhex: and even then, it could be overriden using config files ;)
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:06:33 < meebey!meebey@booster.qnetp.net: so a pure 2.0 environment without 1.1 is only possible if all libs in between are 2.0
oftc/2008-08/#debian-mono.08.log-08-08-2008 11:06:37 < meebey!meebey@booster.qnetp.net: thats how MS does it too I think

oftc/2008-08/#debian-mono.27.log:27-08-2008 22:15:56 > directhex: so gtk# depends on libmono-system1.0-cil | libmono-system2.0-cil and so on
oftc/2008-08/#debian-mono.27.log-27-08-2008 22:15:59 < meebey!meebey@booster.qnetp.net: gah we had that twice already, its a dead end
oftc/2008-08/#debian-mono.27.log:27-08-2008 22:17:20 < meebey!meebey@booster.qnetp.net: libmono-system1.0-cil | libmono-system2.0-cil is wrong by definition as it depends on the application that uses the lib which runtime will be active
oftc/2008-08/#debian-mono.27.log-27-08-2008 22:17:56 > directhex: exactly. can't we track the specifics at app-level, by following the deps up the tree?
oftc/2008-08/#debian-mono.27.log-27-08-2008 22:18:27 > directhex: i suppose just telling people "use --runtime" is just plain easier
oftc/2008-08/#debian-mono.27.log-27-08-2008 22:18:42 < meebey!meebey@booster.qnetp.net: no and yes
oftc/2008-08/#debian-mono.27.log-27-08-2008 22:19:24 < meebey!meebey@booster.qnetp.net: at least no with the current way debhelper and dh_*cli* or dh_*sh* works
oftc/2008-08/#debian-mono.27.log-27-08-2008 22:19:56 < meebey!meebey@booster.qnetp.net: its simply not worth it, 1.0 will be obsolete, 2.0 will be default
oftc/2008-08/#debian-mono.27.log-27-08-2008 22:20:17 < meebey!meebey@booster.qnetp.net: I dont know any real app that uses 1.0...
oftc/2008-08/#debian-mono.27.log-27-08-2008 22:20:26 < meebey!meebey@booster.qnetp.net: even smuxi uses 2.0!
oftc/2008-08/#debian-mono.27.log-27-08-2008 22:20:31 < meebey!meebey@booster.qnetp.net: ;)

oftc/2008-07/#debian-mono.24.log:24-07-2008 13:31:47 > directhex: can you see what i'm getting at? conceptually, could a few things which depend on corlib 1.0 depend on 1.0|2.0 with some gentle massaging? e.g. make the "gacutil" shell script run gacutil.exe using whichever corlib is installed rather than only 1.0
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:31:55 < Mirco!~mirco@stalin.gsd-software.net: but forced to use 2.0 runtime for a 2. starter
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:32:24 < Mirco!~mirco@stalin.gsd-software.net: thats tricky
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:32:58 < Mirco!~mirco@stalin.gsd-software.net: dh_makeclilibs cant know it
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:33:02 < Mirco!~mirco@stalin.gsd-software.net: well with hacks maybe
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:33:08 < Mirco!~mirco@stalin.gsd-software.net: replacing 1.0 with 2.0 in the package name
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:33:14 < Mirco!~mirco@stalin.gsd-software.net: and add it as |
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:33:29 < Mirco!~mirco@stalin.gsd-software.net: if the lib is linked with 1.0
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:33:33 < Mirco!~mirco@stalin.gsd-software.net: 2.0 is not backwards comp
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:33:37 < Mirco!~mirco@stalin.gsd-software.net: but 1.0 is forward comp
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:33:49 > directhex: hrm
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:33:51 < Mirco!~mirco@stalin.gsd-software.net: regarding the runtime profile
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:34:04 < Mirco!~mirco@stalin.gsd-software.net: and only true for runtime libs
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:34:10 < Mirco!~mirco@stalin.gsd-software.net: normal libs are not this way
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:34:11 < Mirco!~mirco@stalin.gsd-software.net: not mapped
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:34:38 < Mirco!~mirco@stalin.gsd-software.net: so we could add such mapping hack to dh_makeclilibs for the mono libs
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:34:53 < Mirco!~mirco@stalin.gsd-software.net: errr wait
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:34:55 < Mirco!~mirco@stalin.gsd-software.net: actually
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:34:56 < Mirco!~mirco@stalin.gsd-software.net: dude
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:35:27 < Mirco!~mirco@stalin.gsd-software.net: you can override the generated deps
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:35:37 < Mirco!~mirco@stalin.gsd-software.net: so the mono source package simply needs it
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:35:44 < Mirco!~mirco@stalin.gsd-software.net: for all libs that are mapped
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:35:48 > directhex: i count 9.7M of space on disk used by 1.0 classlib in order to install tomboy
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:35:49 < Mirco!~mirco@stalin.gsd-software.net: this could work
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:35:55 < Mirco!~mirco@stalin.gsd-software.net: directhex: cool
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:37:19 > directhex: libmono-corlib1.0-cil, libmono-data-tds1.0-cil, libmono-i18n1.0-cil, libmono-security1.0-cil, libmono-system-data1.0-cil, libmono-system-web1.0-cil, libmono-system1.0-cil, libmono1.0-cil, libmono-sharpzip0.84-cil
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:38:08 < Mirco!~mirco@stalin.gsd-software.net: so what we actually change/implement is the remapping of references to runtime libraries if run under the 2.0 profile
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:38:13 < Mirco!~mirco@stalin.gsd-software.net: ooohhh thats the issue...
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:38:24 < Mirco!~mirco@stalin.gsd-software.net: you cant know which profile it will run on
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:38:25 < Mirco!~mirco@stalin.gsd-software.net: e.g.
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:38:31 < Mirco!~mirco@stalin.gsd-software.net: you have boo.exe (1.0)
--
oftc/2008-07/#debian-mono.24.log:24-07-2008 13:38:57 < Mirco!~mirco@stalin.gsd-software.net: you cant make the dep libmono1.0-cil | libmono2.0-cil now
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:39:20 < Mirco!~mirco@stalin.gsd-software.net: as simply libmono2.0-cil would crash
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:39:30 < Mirco!~mirco@stalin.gsd-software.net: if libmono1.0-cil not installed, which boo.exe linked
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:39:33 < Mirco!~mirco@stalin.gsd-software.net: ugly
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:39:42 < Mirco!~mirco@stalin.gsd-software.net: so it needs to be a hack in dh_clideps
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:39:54 < Mirco!~mirco@stalin.gsd-software.net: way more complicated there
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:40:08 < Mirco!~mirco@stalin.gsd-software.net: so the clilibs would stay the same
oftc/2008-07/#debian-mono.24.log-24-07-2008 13:40:15 < Mirco!~mirco@stalin.gsd-software.net: must stay the same...