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
On Sun, Sep 20, 2015 at 11:33 AM, Christof Stocker < [email protected]> wrote: > 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? > > > On 2015-09-20 20:23, Elliot Saba wrote: > > 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. >>> >>> > >
