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 <http://buildbot.e.ip.saba.us:8010/waterfall?category=Packaging> 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 <https://github.com/staticfloat/julia-buildbot/blob/master/commands/launchpad.sh>. The results of running that script are saved on the buildbot website linked above, here's a link to the latest run <http://buildbot.e.ip.saba.us:8010/builders/package_launchpad/builds/1574/steps/Run%20launchpad.sh/logs/stdio> 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 <https://github.com/staticfloat/julia-debian>, 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 On Sun, Sep 20, 2015 at 8:55 AM, Tony Kelman <[email protected]> wrote: > 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. > > > On Sunday, September 20, 2015 at 8:37:57 AM UTC-7, Glen O wrote: >> >> 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. >> >> On Monday, 21 September 2015 00:47:10 UTC+10, Tony Kelman wrote: >>> >>> 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. >> >>
