Pin ffi to 1.12.x, for compatibility with Ruby 2.0

[fidothe]

ffi 1.13 requires Ruby 2.3, which is not supplied by many still-supported distros (e.g Centos/RHEL 7), 1.12.X works there, so restrict to that.

Addresses #1708

[luto]

This would be great to have to fix fpm on CentOS 7 :)

[jordansissel]

I agree this fix would be helpful for folks stuck on older/abandoned versions of Ruby (v2.0 was EOL 4 years ago). I am in favor of these kinds of fixes!

I need help testing this change on other platforms to understand any possible negative impacts of this change.

[joespitch]

FYI I also just encountered this error on CentOS 7, but was able to work around it by just installing RVM and setting the default version to 2.3.3:

curl -sSL https://rvm.io/mpapis.asc | gpg --import -
curl -L get.rvm.io | bash -s stable
source ${HOME}/.rvm/scripts/rvm
rvm reload
rvm install 2.3.3
rvm use 2.3.3 --default
gem install --no-document fpm

after that, the FPM installation worked as normal - and FPM also worked.

[lleroyconsult]

Any news on this PR ?

[sajjad037]

I had faced a similar error on Oracle Linux 7.x and the workaround that I followed to fix it was, after installing the prerequisites packages. Install the ffi 1.9.14 package First and then install the fpm.

gem install ffi -v '1.9.14'
# then installed fpm
gem install --no-ri --no-rdoc fpm
fpm --version
Doing `require 'backports'` is deprecated and will not load any backport in the next major release.
Require just the needed backports instead, or 'backports/latest'.
1.11.0

[jordansissel]

I am OK with this change, though I don't know what negative impact this will have on newer rubies, if any. I briefly reviewed the changelog for ruby ffi and 1.12.2 is a year old at this point which seems recent enough. Seems safe to make this change.

[felixbuenemann]

@jordansissel This change breaks compatibility with arm64 based Macs, since they require ffi 1.14.0 or newer.

Can't systems with outdated Rubies just install an older version of the ffi gem manually?

[luto]

@felixbuenemann Installing an older ffi version prior to fpm works fine as documented in #1709 (comment), yes. We've been doing that for months.

[fosskers]

This seems to prevent the fpm package on Arch from being updated, since only ruby-ffi-1.15.0 is available. I will do some experimentation.

See also #1768

[fosskers]

Got through it by patching the ffi bounds in the PKGBUILD:

  sed -i 's/"ffi", "~> 1.12.0"/"ffi", ">= 1.15.0"/' fpm.gemspec

[felixbuenemann]

I'm voting to revert this change.

Breaking newer Rubies to support an outdated Ruby version that is EOL a long time is not a good idea…

Users of such old Rubies can install a compatible version of the ffi gem by pinning to an old version using bundler, as long as the gemspec does not exclude those versions.

[jordansissel]

I’m not sure yet what good solution might exist for this problem. On one hand, there are many systems which cannot reasonably upgrade their version of Ruby, and “gem install fpm” will fail if we don’t pin ffi. It doesn’t matter much to me that they’re EOL — they’re still in production. The other hand, newer rubies are broken when we pin. It’s not great to choose which large population of users to hurt. I’m open to ideas. Maybe we can fix this somehow in the documentation to express how older Ruby users can successfully use fpm when ffi is unpinned?

…

On Fri, Mar 19, 2021 at 8:38 AM Felix Bünemann ***@***.***> wrote: I'm voting to revert this change. Breaking newer Rubies to support an outdated Ruby version that is EOL a long time is not a good idea… Users of such old Rubies can install a compatible version of the ffi gem by pinning to an old version using bundler, as long as the gemspec does not exclude those versions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1709 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAF2X2ZAJXBXFXEH5BSB3TENVWBANCNFSM4NRXPW2Q> .

[fosskers]

For sure this is a problem that many open source projects have to come to a fair conclusion on. Namely:

When do we leave (real or hypothetical) users behind?

or more technically:

What should fpm's support window be?

The latter is clearer, as fpm already has an implicit support window. Surely Ruby 1.0 users aren't being considered here, although perhaps there are a few still lurking around, who could potentially want fpm? We typically can't support an infinitely wide backcompat window, as after a while projects grind to a halt under the weight of the workarounds that are often necessary.

So we're caught between two poles: the necessity of keeping up with the evolving ecosystem (or we stagnate) and the necessity of considering users who for reasons possibility out of their control cannot keep up with us. So now we're just negotiating: what's a reasonable support window for fpm?

It's my personal feeling that if backcompat is preventing forward-compat, the support window should be narrowed to exclude offending EOL Rubys. I would say it is somewhat standard practice to consider users of any EOL software (be it Python 2 or Windows XP, etc.) to be "on their own".

[jordansissel]

To give you an idea of where I typically stand on support windows, fpm was likely one of the last projects which still supported Ruby 1.8. The idea of support Windows often focuses on the developer/product team, in my experience. However, as fpm’s target audience includes sysadmin/operators who often have no choice about their operating system platform upgrade schedules, I have tended to support old rubies. There were many years where Ruby 1.8 had been long abandoned by the Ruby development team but was still the only Ruby version available on CentOS 6/7. It’s mostly dependencies that abandon old rubies which force fpm to follow. Usually the `backports` gem helps me defend against this pressure, but C extensions like ffi aren’t covered by backports. I still support 1.8, but it’s very hard to get some gem dependencies to run on it.

…

On Fri, Mar 19, 2021 at 10:14 AM Colin Woodbury ***@***.***> wrote: For sure this is a problem that many open source projects have to come to a fair conclusion on. Namely: When do we leave (real or hypothetical) users behind? or more technically: What should fpm's support window be? The latter is clearer, as fpm already has an implicit support window. Surely Ruby 1.0 users aren't being considered here, although *perhaps* there are a few still lurking around, who could potentially want fpm? We typically can't support an infinitely wide backcompat window, as after a while projects grind to a halt under the weight of the workarounds that are often necessary. So we're caught between two poles: the necessity of keeping up with the evolving ecosystem (or we stagnate) and the necessity of considering users who for reasons possibility out of their control cannot keep up with us. So now we're just negotiating: what's a reasonable support window for fpm? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1709 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAF2RJQNJFNTTRJFYCGH3TEOA75ANCNFSM4NRXPW2Q> .

[jordansissel]

This change breaks compatibility with arm64 based Macs

I'm still not sure how best to solve this. It feels like the only way to solve this is by having some separate installation steps based on the ruby version?

That is, revert this change and require ffi with no version constraint, and then have the documentation provide a table of safe ffi+ruby versions? This feels like a bad solution that'll also break things (requiring some amount of surprise work) for folks who have automation using fpm installation?

I wonder if the folks at ffi have any suggestions.

[jordansissel]

I filed an issue upstream for advice since I'm not coming up with any solid ideas right now -- ffi/ffi#906 -- perhaps the kind ffi folks might have ideas. I'm hoping they've had similar concerns in the past. Maybe we'll get lucky ;)