The Mono 2.0 transition (and how to survive it)

[Jo Shields]

Dear all,

Mono is changing.

The Debian pkg-mono team is making changes to the structure of Mono
packaging, which will help shrink the disk footprint of applications
like Tomboy or F-Spot. However, it requires a packaging transition, and
for that, we need your help.

== A transition? Why? ==

Well, in the first instance, a small transition would be needed anyway -
tools which were previously in one package must be moved to other
packages, due to altered dependencies. We decided to instigate a major
change instead, one which allows us to do three cool new things:

* Change the default compiler, and therefore the version of CLR an app
or lib is built against, with a bare minimum of fuss
* Strip the dependencies of some packages, so a package which uses
Mono.Posix.dll for i18n support no longer pulls in SQLite due to some
convoluted dependencies
* Build a 2.0-pure CLR system. Currently, an application like Tomboy
might be 2.0-based, but the widget toolkit (GTK#) is 1.0, and the tools
for handling library installation are 1.0, so you end up with both 1.0
and 2.0 versions of many libraries to run a 2.0 only application - we
think this is silly, so are changing it.

Points 2 and 3 above are what allow us to make significant savings on
the disk space used by the Jaunty LiveCD, post-transition (between 10
and 20 MiB, or 20-40% of Tomboy+deps on-disk footprint).



== What is needed? ==

The package transition needs to happen in three stages.

Firstly, we need a new "core mono stack" in place (9 source packages,
tracked in pkg-mono on Alioth). These introduce the new build dependency
metapackages.

Secondly, all (yes, all) Mono-based applications (anything without
reverse-depends in other source packages; applications with a split
library package not used by other apps is fine) need to migrate to the
new packaging rules.

Thirdly, alter libraries to the new packaging rules. By migrating
libraries after applications, we ensure that there are no 1.0-only
applications trying to use 2.0-only libraries (whereas 2.0 applications
can load 1.0 libraries fine)



== Why do it in Ubuntu? ==

Debian is in freeze right now, which is killing us. Debian's NEW queue
is extremely slow to process packages with a transition, which is also
killing us. Generally speaking, it's very hard within Debian to prepare
all these changes in a timely manner. That's why we've decided to try
and harness the power of Ubuntu and the MOTUs to help us with the
time-consuming part (migrating apps & libs)



== So how can I help? ==

It is unlikely that you can help with phase 1 - that'll be between me,
ubuntu-main-sponsors, and a couple of other people such as Mirco Bauer
and David Paleino, who are preparing the core packages in SVN.

Stages 2 and 3 are where Ubuntu can show off what a team like the MOTUs
can achieve - the prediction I've been given for doing this work
independently is 1-2 months, I reckon Ubuntu can get it done in a
fraction of the time.

I've written instructions for packagers, following an example package.
These are detailed on
http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition#head-67c13a005dab7f510b0fd1ee8db7a30689e89669 but I'll repeat the basics here:
1) Change your build-dependencies and replace all mono-{g}mcs,
mono-X-devel and mono-gac dependencies with: "mono-devel"
2) Bludgeon the build system into using 'csc' as a compiler, instead of
'mcs' or 'gmcs'. The wiki page gives a patching example, and a
debian/rules environment variable example



== So I just make a Xubuntu1 package? ==

Yes, but there are a few guidelines which will really help with the
Ubuntu-Debian relationship:

* If you need to make a change to something in a package's debian/
folder, please send a .diff to pkg-mono-devel at lists.alioth.debian.org
with that change

* If you need to make a change to something outside a package's debian/
folder, please send a .dpatch to pkg-mono-devel at lists.alioth.debian.org

* If you need to make a change to something outside a package's debian/
folder, and the package does not already build-depend on dpatch, then
please integrate dpatch into the build process, create a .dpatch with
the change you wanted to make, and send a .diff of the processed package
(both adding dpatch, and the dpatch file itself, in the same diff) to
pkg-mono-devel at lists.alioth.debian.org

* If the package in question is not really a Mono package, but has a
version in Debian Experimental (OOo, I'm looking at you), then please CC
them any patches (as the migration will affect them too soon) via their
preferred contact mechanism

* If you notice a package is team-maintained by pkg-mono, but hasn't
seen any love in a while, consider making an upstream version update,
and telling us about it. Perhaps you could even take over that package
in our SVN repository, benefiting both distributions now & later?

* If you notice a package is not team-maintained by pkg-mono, but hasn't
seen any love in a while, consider making an upstream version update,
and telling us about it. Perhaps you could even take over that package
in our SVN repository, benefiting both distributions now & later?

* If you're not sure what to do, contact us (see below)



== It's all broken. Do we get support on this? ==

Yes. If you want interactive support, please join #debian-mono on OFTC.
For mail-based support, please contact
pkg-mono-devel at lists.alioth.debian.org

I should set up a wiki.debian.org page for collaboration (or at least so
people can register what they're working on), but it's pretty late and I
doubt I'll get time tonight.



== So when does this all begin? ==

When someone from ubuntu-main-sponsors gives some love to
https://bugs.edge.launchpad.net/ubuntu/+source/mono/+bug/300133




Thanks for taking the time to read through this. I look forward to
trying to work though any concerns or issues you may have, to help make
this a smooth transition.

--Jo Shields

P.S. please CC me in any replies, I'm not subscribed to either of these
lists
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20081120/8fa85ce1/attachment.pgp