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]
<mailto:[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.
