IronPython and Mono are very old. How can we get an update?

[Christopher James Halse Rogers]

On Fri, Apr 8, 2011 at 2:31 AM, Vernon Cole <vernondcole at gmail.com> wrote:
> On Thu, Apr 7, 2011 at 6:26 AM, chalserogers at gmail.com
> <chalserogers at gmail.com> wrote:
> [...]
>> Mono's upstream 2.10 release page suggests that they're shipping both
>> IronPython and IronRuby in the main mono distribution, but looking at
>> the source I can't find it, so I'm not sure what's happening there.
>
> IronPython and IronRuby are now building from the same source.
>  https://github.com/IronLanguages/main
>
>> Regardless, Mono 2.10.1 is now available in Debian experimental, and
>> so will be available early on in the Oneiric (what will become Ubuntu
>> 11.10) development cycle.  Since we're very close to the end of the
>> Natty cycle upgrading to 2.10.1 presents too big a regression risk to
>> pull it in this time.
>>
>> What needs to be done is to update the dlr-languages² source package.
>> This is maintained by the pkg-cli-libs team in Debian, and we sync it
>> across from there.  As we're well after Natty feature freeze, updating
>> in Natty would require a Feature Freeze exception¹.  As there seems to
>> be only one package with a(n optional) dependency on IronPython in the
>> archive it *might* be possible to get an FFe and have the new package
>> in the Natty release, it would be more reasonable to aim for Oneiric.
>
> One can RUN IronPython 2.7 on Mono 2.6.7, but not BUILD it,
> http://ironpython.codeplex.com/wikipage?title=IronPython%20on%20Mono
> So I'm not sure how well an FFe would work.

Oh.  Yeah, that's not going to work then!

> I'm assuming that the
> build engine runs on the same Mono version as the release?

Yes.  The policy is that everything in the archive has to be built by
tools in the archive.

>
>  Perhaps we will need to maintain a .NET 2.0 compatible binary of IPy
> on the IronPython site until well after Debian releases with Mono 2.10
> under the hood.
>

Debian stable is going to have Mono 2.6.7 until the next release,
which is likely to be about 2 years away.  There's likely to be a
backport done, though, so it should (eventually) be reasonably easy
for Debian users to have Mono 2.10.  Ubuntu 11.10 will have Mono 2.10,
Ubuntu 11.04 won't - but, again, is likely to get *some* sort of
backport, even through a PPA.  Whether that makes it worth maintaining
a 2.0-compatible IPy is up to you :).

>> If you'd like help in the mechanical process of updating the package,
>> the Ubuntu packaging guide³ has a good rundown, or feel free to ask -
>> IRC #debian-cli on oftc.net is friendly and generally active.  Since
>> it looks like dlr-languages is one of the more complex things to
>> package, I could probably find the time to update it in the next month
>> or so if you're not comfortable with the process.
>>
> ¹: https://wiki.ubuntu.com/FreezeExceptionProcess
> ²: http://git.debian.org/?p=pkg-cli-libs/packages/dlr-languages.git;a=summary
> ³: https://wiki.ubuntu.com/PackagingGuide
>
> Okay, I just looked at the link, and would require a month or so for
> me to figure out how to do it. I have been a bit hesitant about
> changing things I don't understand, ever since I crashed the Internet
> in several neighboring states by incorrectly updating a gateway
> router. (Long story, and the Internet was much smaller then.) So, yes,
> please make those changes when you can.  :-)

Well, we'd be reviewing and sponsoring your changes, so if you *did*
break the Internet again it'd be our fault :).

>
> Make sure that the source is coming from github, not codeplex.
> I'll see that the build patches get into a new tarball, They are now
> in the git trunk but not backported to the 2.7 maintenance branch yet.
> How often do you fetch a new tarball?

As often as the maintainer feels like it.  For well maintained
packages (here's where you can come in ☺) that's generally once per
upstream release, unless there's some problem - like it not being
buildable against Mono 2.6.7 :).

There's a certain amount of impedance mismatch between Debian and
predominantly-Windows upstreams like Iron*, but that's something that
can largely be worked around.  The biggest problem is probably the
different IronPython/IronRuby release schedules which mean we can't
have IronPython 2.7 and IronRuby 1.0 unless we have two different
source packages, and even then there's the problem of the shared DLR
component.