FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Masters Of The Universe

 
 
LinkBack Thread Tools
 
Old 11-20-2008, 12:02 AM
Jo Shields
 
Default The Mono 2.0 transition (and how to survive it)

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@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@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@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@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
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 11-20-2008, 12:02 AM
Jo Shields
 
Default The Mono 2.0 transition (and how to survive it)

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@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@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@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@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
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-20-2008, 10:21 AM
Scott Kitterman
 
Default The Mono 2.0 transition (and how to survive it)

On Thu, 20 Nov 2008 01:02:55 +0000 Jo Shields <directhex@apebox.org> wrote:
...
>== So I just make a Xubuntu1 package? ==
>
>Yes, but there are a few guidelines which will really help with the
>Ubuntu-Debian relationship:
>
...

Since we are early in the Jaunty cycle yet, would it be feasible (at least
where pkg-mono is Maintainer) for the needed changes to be provided to the
team via mail, svn, etc., uploaded to Debian Experimental, and then Ubuntu
does a sync from there?

This would minimize the Debian/Ubuntu diff, springload Debian for Squeeze,
and reduce risk of problems that come up when Ubuntu gets ahead of Debian
(such as orig.tar.gz with different md5sum that then has to be fake
sync'ed).

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 11-20-2008, 10:21 AM
Scott Kitterman
 
Default The Mono 2.0 transition (and how to survive it)

On Thu, 20 Nov 2008 01:02:55 +0000 Jo Shields <directhex@apebox.org> wrote:
...
>== So I just make a Xubuntu1 package? ==
>
>Yes, but there are a few guidelines which will really help with the
>Ubuntu-Debian relationship:
>
...

Since we are early in the Jaunty cycle yet, would it be feasible (at least
where pkg-mono is Maintainer) for the needed changes to be provided to the
team via mail, svn, etc., uploaded to Debian Experimental, and then Ubuntu
does a sync from there?

This would minimize the Debian/Ubuntu diff, springload Debian for Squeeze,
and reduce risk of problems that come up when Ubuntu gets ahead of Debian
(such as orig.tar.gz with different md5sum that then has to be fake
sync'ed).

Scott K

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-20-2008, 10:42 AM
Jo Shields
 
Default The Mono 2.0 transition (and how to survive it)

On Thu, 2008-11-20 at 06:21 -0500, Scott Kitterman wrote:
> On Thu, 20 Nov 2008 01:02:55 +0000 Jo Shields <directhex@apebox.org> wrote:
> ...
> >== So I just make a Xubuntu1 package? ==
> >
> >Yes, but there are a few guidelines which will really help with the
> >Ubuntu-Debian relationship:
> >
> ...
>
> Since we are early in the Jaunty cycle yet, would it be feasible (at least
> where pkg-mono is Maintainer) for the needed changes to be provided to the
> team via mail, svn, etc., uploaded to Debian Experimental, and then Ubuntu
> does a sync from there?

Assuming the NEW delay doesn't cause too many problems (let's say Mono
takes another month from now - that's basically DIF), then YES!
Absolutely. That's the best-case scenario we'd like.

One of my major release goals for Jaunty has been to make Mono itself
syncable - if not for this silly time delay, then it would be the case
right now. The more syncs, the better for everyone.

> This would minimize the Debian/Ubuntu diff, springload Debian for Squeeze,
> and reduce risk of problems that come up when Ubuntu gets ahead of Debian
> (such as orig.tar.gz with different md5sum that then has to be fake
> sync'ed).

That's the plan.

See also the very much in-progress
http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO which
shows versions in Sid, Experimental, and Jaunty.

Packages with a Jaunty version but no Sid version are missing from
Debian, and it would be nice if the original uploader could ITP it.
Packages with a XubuntuY version... are your changes not beneficial to
Debian too? Why not push them up while you're at it?

--Jo Shields


--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 11-20-2008, 10:42 AM
Jo Shields
 
Default The Mono 2.0 transition (and how to survive it)

On Thu, 2008-11-20 at 06:21 -0500, Scott Kitterman wrote:
> On Thu, 20 Nov 2008 01:02:55 +0000 Jo Shields <directhex@apebox.org> wrote:
> ...
> >== So I just make a Xubuntu1 package? ==
> >
> >Yes, but there are a few guidelines which will really help with the
> >Ubuntu-Debian relationship:
> >
> ...
>
> Since we are early in the Jaunty cycle yet, would it be feasible (at least
> where pkg-mono is Maintainer) for the needed changes to be provided to the
> team via mail, svn, etc., uploaded to Debian Experimental, and then Ubuntu
> does a sync from there?

Assuming the NEW delay doesn't cause too many problems (let's say Mono
takes another month from now - that's basically DIF), then YES!
Absolutely. That's the best-case scenario we'd like.

One of my major release goals for Jaunty has been to make Mono itself
syncable - if not for this silly time delay, then it would be the case
right now. The more syncs, the better for everyone.

> This would minimize the Debian/Ubuntu diff, springload Debian for Squeeze,
> and reduce risk of problems that come up when Ubuntu gets ahead of Debian
> (such as orig.tar.gz with different md5sum that then has to be fake
> sync'ed).

That's the plan.

See also the very much in-progress
http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO which
shows versions in Sid, Experimental, and Jaunty.

Packages with a Jaunty version but no Sid version are missing from
Debian, and it would be nice if the original uploader could ITP it.
Packages with a XubuntuY version... are your changes not beneficial to
Debian too? Why not push them up while you're at it?

--Jo Shields


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-20-2008, 12:06 PM
Jo Shields
 
Default The Mono 2.0 transition (and how to survive it)

On Thu, 2008-11-20 at 06:21 -0500, Scott Kitterman wrote:
> On Thu, 20 Nov 2008 01:02:55 +0000 Jo Shields <directhex@apebox.org> wrote:
> ...
> >== So I just make a Xubuntu1 package? ==
> >
> >Yes, but there are a few guidelines which will really help with the
> >Ubuntu-Debian relationship:
> >
> ...
>
> Since we are early in the Jaunty cycle yet, would it be feasible (at least
> where pkg-mono is Maintainer) for the needed changes to be provided to the
> team via mail, svn, etc., uploaded to Debian Experimental, and then Ubuntu
> does a sync from there?
>
> This would minimize the Debian/Ubuntu diff, springload Debian for Squeeze,
> and reduce risk of problems that come up when Ubuntu gets ahead of Debian
> (such as orig.tar.gz with different md5sum that then has to be fake
> sync'ed).

Okay, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO
should now be complete enough to use for reference

Developers, please take a peek at the list to see if this transition
affects you directly - or whether you are in a position to help.
Packages which are marked as a "yes" to pkg-cli means we are in a
position to directly upload a new version to Experimental (for syncing)
- packages which are not marked as Yes may require further coordination
with their maintainers

--jo Shields


--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 11-20-2008, 12:06 PM
Jo Shields
 
Default The Mono 2.0 transition (and how to survive it)

On Thu, 2008-11-20 at 06:21 -0500, Scott Kitterman wrote:
> On Thu, 20 Nov 2008 01:02:55 +0000 Jo Shields <directhex@apebox.org> wrote:
> ...
> >== So I just make a Xubuntu1 package? ==
> >
> >Yes, but there are a few guidelines which will really help with the
> >Ubuntu-Debian relationship:
> >
> ...
>
> Since we are early in the Jaunty cycle yet, would it be feasible (at least
> where pkg-mono is Maintainer) for the needed changes to be provided to the
> team via mail, svn, etc., uploaded to Debian Experimental, and then Ubuntu
> does a sync from there?
>
> This would minimize the Debian/Ubuntu diff, springload Debian for Squeeze,
> and reduce risk of problems that come up when Ubuntu gets ahead of Debian
> (such as orig.tar.gz with different md5sum that then has to be fake
> sync'ed).

Okay, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO
should now be complete enough to use for reference

Developers, please take a peek at the list to see if this transition
affects you directly - or whether you are in a position to help.
Packages which are marked as a "yes" to pkg-cli means we are in a
position to directly upload a new version to Experimental (for syncing)
- packages which are not marked as Yes may require further coordination
with their maintainers

--jo Shields


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 

Thread Tools




All times are GMT. The time now is 03:13 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org