Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Older versions won't build forever. #1775

Closed
NathanZook opened this issue Jun 16, 2021 · 6 comments
Closed

Older versions won't build forever. #1775

NathanZook opened this issue Jun 16, 2021 · 6 comments

Comments

@NathanZook
Copy link

@NathanZook NathanZook commented Jun 16, 2021

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.

@eregon
Copy link
Member

@eregon eregon commented Jun 16, 2021

ruby-build already emits a warning for old unmaintained Rubies:

WARNING: ruby-1.9.3-p551 is past its end of life and is now unsupported.
It no longer receives bug fixes or critical security updates.

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 ruby-build could help much with building ancient versions, it seems basically impossible outside Docker.

openssl 1.0 is a different matter, notably discussed in #1476

@NathanZook
Copy link
Author

@NathanZook NathanZook commented Jun 16, 2021

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.

@eregon
Copy link
Member

@eregon eregon commented Jun 17, 2021

There is a huge difference between "no longer being updated" and "no longer building".

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.
ruby-build never supports a Ruby version more or less than upstream, it fetches the archive and whether it builds depends on the C compiler, dependencies, etc, nothing that ruby-build controls.
So I'm not sure what would be a good way to clarify without starting confusion about "ruby-build support of specific Ruby versions" which is not a thing.

"Older versions won't build forever" applies to every software building software, I don't see what's special here.

@NathanZook
Copy link
Author

@NathanZook NathanZook commented Jun 18, 2021

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.

@thbar
Copy link

@thbar thbar commented Jul 1, 2021

I am not a ruby-build maintainer, but a Ruby maintainer on all types of (legacy/modern) systems, so I'll comment a bit here.

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 rspec/rspec#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 ruby-build even if I definitely understand your frustration, and not every tool is going to be super careful with the way they phrase it.

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...

@eregon
Copy link
Member

@eregon eregon commented Jul 1, 2021

From the message

It no longer receives bug fixes or critical security updates.

There is a huge difference between "no longer being updated" and "no longer building".

No bug fixes means also no build issue fixes.
And ruby-build does not include patches to try to workaround and build old unsupported Rubies.

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 ruby-build as basically convenience for ./configure; make; make install.

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.

@eregon eregon closed this Jul 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants