Julia 0.4 RC ppa?

[Glen O]

With Julia 0.4 now at the stage of Release Candidates, I am interested in upgrading Julia on my Ubuntu laptop from 0.3 to 0.4. I notice that the regular "stable" ppa (juliareleases) is still at 0.3. Meanwhile, the "unstable" ppa (julianightlies) is 0.4 (as expected), but it's marked as 0.4.0-2664 and not 0.4.0-rc1 (and it was compiled before rc2 was released, so I'm assuming it's not rc2).

Is the julianightlies ppa currently providing the release candidates, or is it going to remain with the most recent "unstable" Julia version? If the latter, would it be possible for the juliareleases ppa to temporarily carry both 0.3 and the 0.4 release candidate? My understanding is that this can be done fairly easily by having transitional packages.

[Tony Kelman]

Actually it would be expected for julianightlies to be providing 0.5-dev nightlies right now but it's been failing to update for some time due to build system changes on master. We have more flexibility and control over the linux tarball binaries than we do over the ppa. I don't think the ppa has any effective mechanism to provide release candidates right now.

[Glen O]

Is there a reason why the juliareleases ppa couldn't provide a julia0.4 package, separately from the currently julia package? I've seen similar things done with packages elsewhere, including within the main ubuntu repositories. Indeed, given the changes happening to the language, perhaps it's a good idea to start keeping major versions of julia separate (that is, make it julia0.3 and julia0.4, with julia being a dependency package that will pull in the latest stable julia (ie/ it will point to julia0.3 until julia0.4 is properly released, then it will point to julia0.4).

This also minimises issues for people who might have julia 0.3 currently installed and are actively using it, and don't want to accidentally update to 0.4 and have to alter all of their code to account for changes in the language - they would just remove the dependency package, and be guaranteed to remain with julia0.3 only.

I do understand why it might be considered too much of a nuisance for the relatively short RC period, when we can wait for the proper release, but I'm probably not the only person who isn't up to using an in-development version (nightlies), but is willing to use one that might just be slightly buggy (release candidate), and who doesn't want to fiddle with installation or compilation.

[Tony Kelman]

Versioning the julia package name in the ppa would be a very good idea. The only reason the PPA is often out of date is that it's entirely maintained by a single person who doesn't always have the time to fix things that break or update things that would usually be handled automatically. As I said it takes more maintenance to keep running than the tarball builds, and since the PPA is Ubuntu-specific we've been encouraging people to use the generic tarballs now since we have more control over dependencies, public visibility to any issues that arise, and the ability for multiple people to fix them. I recognize the utility in having your system package manager handle updates, but it's a fair bit more maintenance work. Downloading and installing a tarball to use the binaries of Julia should be pretty easy, and doesn't need root access either.

[Elliot Saba]

Yep, Tony hit it on the head.  As the maintainer of the Ubuntu PPA, I definitely understand the usefulness and ease of having Julia managed by the system package manager, but unfortunately the build process is relatively difficult to debug/fix; we have to jump through quite a few hoops to get our source packages ready for building on the Canonical servers, and problems often arise and must wait a few weeks before I can fix them.

To give you an idea of the workflow we have setup right now, the first step is that a job is run on the buildbots called "package_launchpad", which gets run every time a commit passes the automated testing and bundles that commit up into a form ready to be submitted to launchpad.  The script that is run by that buildbot job is right here.  The results of running that script are saved on the buildbot website linked above, here's a link to the latest run which is the first to succeed in a while, due to some incorrect configuration after I rebuilt the VM images a few weeks ago in preparation for 0.4 releases.  One of the pieces of preparation that the script performs is to embed a debian directory from this repository, which gives the rules and metadata necessary to build a Debian package for Julia.

As far as providing a `julia0.4` package, that is an interesting idea that may be the best way forward, but unfortunately I have many other projects that are vying for my attention right now.  If anyone reading this is interested in pushing forward on that particular effort, even if you don't have much experience working on this kind of stuff, please do not hesitate to contact me to get more information on how to start, or just start submitting pull requests/forking things.

In the meantime, just like Tony said, I think the best bet is to use the generic linux tarballs for now.  In all honesty, there's really only one concrete benefit to the PPA binaries (other than the simple purity of having things managed by dpkg rather than being downloaded and installed to user-directories) and that is automatic updates.

Now that I think about it; there's a possibility that a "dummy" .deb could be created that just downloads the latest `.tar.gz`, unpacks it into `/usr`, and calls it a day.

-E

[Christof Stocker]

So bottomline what does this mean for the upcoming 0.4 release. Is the deb not going to be updated for stable releases anymore, or are you just talking about managing different versions at the same time?

[Elliot Saba]

The stable PPA will be updated for 0.4 final, but not with release candidates.  Julianightlies will continue to track the master branch, that is, 0.5-dev.  Creating per-version julia packages is a good idea, but not one that will happen soon, due to my own time constraints.

-E