On Fedora, this results in a nice "Fedora 19" identifier and doesn't
show the codename "Schrödinger’s Cat" which is otherwise contained in
`/etc/fedora-release`.
On Arch, this shows "Arch Linux" where previously we had no info for it
(for some reason, `/etc/arch-release` is empty).
http://www.freedesktop.org/software/systemd/man/os-release.html
Stable releases should now be sorted as a higher version than preview
releases or RCs. For instance:
- 1.9.3-preview < 1.9.3-rc1 < 1.9.3-p0
- 2.1.0-dev < 2.1.0-rc1 < 2.1.0
- jruby-1.7.0-preview1 < jruby-1.7.0-rc1 < jruby-1.7.0
This detects when `/tmp` has been mounted with "noexec" mode and avoids
the cryptic error:
./configure: Permission denied
Hopefully the information provided will be enough for the user to know
that they have to change TMPDIR to another location.
It appears that regular `make` that ships on FreeBSD 10 is compatible
enough to build Rubies. This enables ruby-build on fresh FreeBSD
installs (which don't have `gmake` by default) without having to
explicitly set `MAKE=make`.
Since `./configure` executes in a bash subshell, it failing would
execute the ERR trap twice: once in a subshell and once in the main
process. An explicit `return 1` skips one of these ERR traps and fixes
double output.
I hope.
[image of I Have No Idea What I'm Doing dog]
The `-v` option for tar has been here since the beginning of ruby-build,
but it's not really informative to see a list of files in the log as the
list of files is guaranteed to be the same across machines since we do
checksums.
But don't assume that RUBY_BUILD_ROOT is where ruby-build's own files
reside, since RUBY_BUILD_ROOT can be overriden with alternate definition
files location.
Filenames in git diff patches are prefixed by default by "a/" (source)
and "b/" destination. Such patches don't work with ruby-builds `--patch`
option since it internally uses `patch -p0`.
Prior workarounds were to use either an intermediate step:
filterdiff --strip=1
or to generate the patch without the prefix in the first place:
git diff --no-prefix ...
Now, git diff patches are detected by searching for this pattern:
diff --git a/...
And `patch -p1` is used by default in such cases to strip the 1st
component of filename paths.
Fixes#521, closes#484
From patch(1):
-f or --force
Assume that the user knows exactly what he or she is doing, and do not
ask any questions. Skip patches whose headers do not say which file is
to be patched; patch files even though they have the wrong version for
the Prereq: line in the patch; and assume that patches are not reversed
even if they look like they are. This option does not suppress commen-
tary; use -s for that.
Fixes#555
Seems like sed 4.1.5 on RHEL 5.3 doesn't support `-E`, and sed on OS X doesn't
support `-r` to activate the extended regexp mode. Best to avoid extended regexp
altogether for compatibility.
Fixes#495
If there already exists a valid tarball in the build location, e.g. as
artefact of a previous install using `--keep`, don't re-download the
file, as there is no need.
References #487
Previously, curl and wget were instructed to try to resume the download
if the destination file already exists. This is supposed to be done via
the "Range" HTTP header, but doesn't work well with CloudFront:
HTTP server doesn't seem to support byte ranges. Cannot resume.
CloudFront is supposed to support ranges, so I don't know what's going
on here. It might be failing only in case the existing file is a fully
downloaded tarball?
In any case, this disables resuming downloads and resorts to simply
re-downloading the tarball always, overwriting the existing file.
Fixes#487
Better to use -f than -e to check for a user-specified definition file.
With -e, if the user accidentally types the name of a directory (or, far
less likely, a device file) with the same name as the Ruby they're
trying to install, they end up with ruby-build doing absolutely nothing
at best, or an error message that could be pretty confusing at worst.
JRuby 9000 (the next major release) includes a backend that supports a
new JVM JIT compiler called Graal. Graal is based on OpenJDK but hasn't
been released yet.
http://openjdk.java.net/projects/graal/
