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...