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 [EMAIL PROTECTED] with that change * If you need to make a change to something outside a package's debian/ folder, please send a .dpatch to [EMAIL PROTECTED] * 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 [EMAIL PROTECTED] * 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 [EMAIL PROTECTED] 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
signature.asc
Description: This is a digitally signed message part
-- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
