Older versions won't build forever. #1775
Comments
|
ruby-build already emits a warning for old unmaintained Rubies: Isn't that clear? What kind of policy statement would you expect and where? My understanding is ruby-build relies on upstream Ruby and does not try to patch old Rubies to make them build on new OS. It's out of scope as far as I understand (and such an approach is inherently fragile anyway). I don't think openssl 1.0 is a different matter, notably discussed in #1476 |
|
I take "unsupported" to be explained by the following sentence. There is a huge difference between "no longer being updated" and "no longer building". If ruby-build is not supporting, then I would think that "now unsupported by ruby-build. Additionally, it no longer..." would be much more clear. |
The difference is simply time passing and how compiler evolve in incompatible ways, and not in ruby-build's or ruby's control (once the version is unsupported) really. "Older versions won't build forever" applies to every software building software, I don't see what's special here. |
|
There is a lot of dependency information that ruby-build either has or, I believe, can gain without too much effort, that can be surfaced to help someone if they want to build an out-of-date version of ruby. Making that information available would be most helpful. |
|
I am not a Sharing this also for other readers, I do not know your background much, and maybe you are already well aware of what I'll write, but anyway. In all "practicality", if a Ruby is marked "EOL" (end-of-life), you will pretty much be gradually on your own, and the tooling (all tooling, all gems) will gradually be more and more painful for anyone to use (to the point where some companies have to close shop). This includes all types of meanings, from "we can't help you in general" to "you won't be able to build anything". For the record some of the code I have can only run in a DOSBox emulator, some companies run old snapshots of very old OS just to keep things running until they can digest the cost of migrating etc. Ruby marks versions as EOL officially to send a strong signal. Some important libraries (including enterprise-used librairies) will remain maintained a bit longer, or much longer depending on cases. But at the end of the day even very essential libraries (see https://github.com/rspec/rspec/issues/25) for instance will end up dropping support, because the cost of maintenance is unbearable. Some initiatives exist (e.g. https://railslts.com for Rails) to continue further, but it is not a sustainable path to keep on old versions. Ruby 1.8.7 and 1.9.2 are EOL since 2014 (https://www.ruby-lang.org/en/news/2014/07/01/eol-for-1-8-7-and-1-9-2/). The rest is documented here https://www.ruby-lang.org/en/downloads/branches/. As @eregon wrote, there is nothing specific to Hope this helps nonetheless, my recommendation as a maintainer is to find a safe/sustainable path to upgrade or rewrite the related code, or at some point it will become very "artistic" to run it, and you'll be on your own... |
|
From the message
No bug fixes means also no build issue fixes. I think there is nothing to do here, except maybe make the phrasing clearer, but it seems difficult. It's really upstream Ruby not supporting those old versions anymore. Think of It doesn't try to install dependencies for you as that's bound to fail as OS/package manager evolve, and I think it's better that way. |
I'm working on a gem that I want to be able to run on older versions of ruby. I'm having...issues. (I'm on Mint 19.)
Uninstalling libssl-dev and installing libssl1.0-dev, along with setting CC=gcc-4.8 (the oldest that ships with Mint 19) allowed me to build 1.8.7-p375. Oddly enough, 1.9.0 & 1.9.1 failed, while I was able to get 1.9.2-p330, 1.9.3-p551 and 2.0.0-p648 as well as later 2.x series.
My concern is not so much about my builds today, as what rbenv's policy should be regarding old builds.
One option is to declare that when a version goes out of support officially, rbenv no longer cares about it. That makes me sad, but it is certainly defensible.
Another option is to try to keep up. I expect that there is some non-drastic way to pull in the libssl1.0-dev library into the build for the older versions that are using it. That's easy for today, but as I have already experienced, the mass is much more than that.
Another option would be to keep some sort of tweeks datasheet or perhaps a known good datasheet with data on the major distributions & OSes. For instance, what versions of gcc, yacc/bison, libssl-dev, & etc are known to work. In the event of a failed build, rbenv could reference such a document (or even check against it) to aid the end user.
The current model, where the fail happens with some sort of compiler error that may or may not send you off in a useful direction seem..less than optimal.
In any event, a clearly stated policy would seem to be in order.
I love your work, btw. Thanks.
The text was updated successfully, but these errors were encountered: