Fwd: IronPython and Mono are very old. How can we get an update?
I have been shuttling ideas back and forth between the IronPython and Ubuntu development groups. This is the latest exchange. I have added comments... -- Vernon ---------- Forwarded message ----------
From: Christopher James Halse Rogers <[hidden email]> Date: Thu, Apr 7, 2011 at 5:37 PM Subject: Re: IronPython and Mono are very old. How can we get an update? To: Vernon Cole <[hidden email]>
Cc: [hidden email]
On Fri, Apr 8, 2011 at 2:31 AM, Vernon Cole <[hidden email]> wrote:
> On Thu, Apr 7, 2011 at 6:26 AM, [hidden email] > <[hidden email]> 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 :).
So, it sounds like Doug's offer make a .deb package will be a really good thing for two more years. -- VC
>> 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.
Jeff has corrected my error here, and both the 2.7 branch and the tarball are up to date. -- VC
> 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
This may still be a sticky spot. The tarball does contain IronRuby, but what version? There must be a version identifier somewhere, but it is not obvious. The only Ruby version number I found when hunting around this afternoon was in an .html file, and the version number was 0.1! I'm pretty sure that is wrong.
Perhaps the README file at the IronLanguages root should be edited to document the versions of the contents, or maybe a NEWS file could be added.
And, why does Rogers say "unless we have two different source packages"?
Methinks another round of mail exchanges may be needed here. -- Vernon
Re: Fwd: IronPython and Mono are very old. How can we get an update?
Vernon, thank you very much for handling this!
On Thu, Apr 7, 2011 at 7:26 PM, Vernon Cole <[hidden email]> wrote:
> This may still be a sticky spot. The tarball does contain IronRuby, but
> what version?
Should be 1.1.3.
> There must be a version identifier somewhere, but it is not obvious. The
> only Ruby version number I found when hunting around this afternoon was in
> an .html file, and the version number was 0.1! I'm pretty sure that is
Look for "IronRubyInformationalVersion" in
Languages\Ruby\Ruby\Runtime\RubyContext.cs. But yes, it should be in
the README (and the README should be fleshed out quite a bit, given
that github shows it on the first page).