16263
Comment:
|
16137
|
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...