Add package Ruby (3.0.0)

[tsutsu]

Motivation: Un-retiring the previously-retired Ruby package, as Synology has EOLed their release.
Linked issues: closes #4350

Checklist

• Build rule all-supported completed successfully
• n/a Package upgrade completed successfully
• New installation of package completed successfully

Outstanding problems blocking merge

• SPK_COMMANDS aren't being picked up (i.e. binaries aren't being linked into /usr/local/bin); I think because INSTALLER_SCRIPT is customized. Not sure if that custom installer-script is still necessary.

[hgy59]

@tsutsu Wow, this is a fast contribution!
I was working on this in parallel, but didn't solve the sofisticated prefix configuration (for me the native ruby couldn't find the rubygems.rb)
I plan to cleanup some outdated framework stuff directly on your branch...

[hgy59]

@tsutsu Thanks again for your contribution.
I cleaned up some framework stuff. See my commit message. Don't hesitate to ask when anything is unclear.

Two questions:

• the ruby configure output tells that readline was not found. So we might remove this dependency (or is there an interactive ruby mode that benefits from readline?)
• As ruby 3.0.0 is brand new (released on 12/25/2020), may be we first should create a package with version 2.7.2 or 2.6.6. (may be there are breaking changes in v3.0?).

[tsutsu]

or is there an interactive ruby mode that benefits from readline?

Yes, the Ruby REPL/shell command irb uses readline. It's very helpful when debugging scripts, so IMHO it would make more sense to get this package to use/detect/depend on cross/readline. Without readline support, irb does some strange things (e.g. multiline prompt editing gets wonky; output exceeding one screen vertically ends up in a broken pure-Ruby more-alike pager emulation, rather than using readline's functional less-alike paging; etc.)

may be there are breaking changes in v3.0?

Not too many (see https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/).

The only compatibility-breaking change that I'm aware of, that might affect existing scripts, is a piece of syntax that's exceedingly unusual — implicitly interchanging keyword arguments with a hash positional-arg. This syntax has never been idiomatic, and has been deprecated for a while now. This isn't a Python 2/3 thing; 99.999% of Ruby 2.x projects don't use this syntax. (IIRC it was only even allowed in the first place as legacy compatibility for Ruby 1.x code.)

Otherwise, Ruby 3.0.0 is basically Ruby 2.8. It technically had to do a major version bump for SemVer reasons — it broke a stable API — but it's not a big break. Any sane Ruby code written in the last 10 years will work just fine if run on 3.0.0. And almost all of the not-sane code will work too!

For the sake of continuity / an upgrade path for people using the current Ruby package from Synology, it might still make sense to provide a 2.7.2 package. But that'd be more of a one-shot "legacy" package. Again, this isn't a Python 2/3 situation where 2.x continues to receive updates, and people gradually switch over — there aren't going to be any more 2.x releases after 2.7.2. Up to you whether you want to just put that release out first.

(It'd make sense to me to do this if Package Center had version-pinning capabilities like apt, allowing people to choose to stay on 2.x if they have a script that would be broken by 3.x. But it doesn't, so putting out 2.7.2 will at most be delaying the inevitable by a week/month. Scripts that are broken by 3.x, have been broken (i.e. relying on legacy behavior) for a long, long, long time, so it's not like one more week/month of leniency will change anything. A bit like websites still using Flash in 2021!)

[hgy59]

@tsutsu Thanks for this detailed information.

1. Ruby Version
   IMHO version 3.0.0 seems to be the one we should keep.

2. readline
   For me it looks like ruby readline integration is correctly built. Configure complains only about the readline extension.

These Extensions are not built:

*** Following extensions are not compiled:
dbm:
	Could not be configured. It will not be installed.
	Check ext/dbm/mkmf.log for more details.
gdbm:
	Could not be configured. It will not be installed.
	Check ext/gdbm/mkmf.log for more details.
readline:
	Could not be configured. It will not be installed.
	Check ext/readline/mkmf.log for more details.

Shall we include these ruby extensions?

for readline I already found a solution. It will be built when using libedit instead of readline (readline built with ncurses would work too, but cross/readline is built wth nursesw).

And can you please confirm that irb that we provide here already has the readline capabilities?

[hgy59]

Answer to
Should this package be able to serve as an upgrade for Synology's Ruby?

The SynoCommunity ruby package installs into the folder /var/packages/ruby whether the Synology package uses /var/packages/Ruby (uppercase R).
IMHO we should avoid to use the same internal folder as the synology package does (did).
So my anwser is NO.

[hgy59]

Shall we include these ruby extensions?

To answer my own question:
Finally all extensions are built and included.

[hgy59]

@tsutsu unfortunatlely the change on cross/berkeley triggered the github action to build additional packages that fail. Therefore no build artifacts are available there.

For anyone who needs a latest build for testing I can provide prerelease packages.