FS#71433 - ruby-rb-inotify gemspec has incorrect dependency encoded within, needs to be rebuilt

Attached to Project: Community Packages
Opened by Nogweii (evaryont) - Sunday, 04 July 2021, 10:43 GMT
Last edited by Toolybird (Toolybird) - Thursday, 11 May 2023, 04:09 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

When installing a rubygem, the gem's resulting specification is saved to a file. This file includes a copy of the dependencies and version constraints and is used as a local cache to bundler and rubygems.

The file included in the ruby-rb-inotify package (/usr/lib/ruby/gems/3.0.0/specifications/rb-inotify-0.10.1.gemspec) has the following line:

s.add_runtime_dependency(%q<ffi>.freeze, [">= 1.0"])

This does not match the upstream Rubygems host (https://rubygems.org/gems/rb-inotify) which specifies the version constraint using the pessimistic operator ("~> 1.0").

This different does not cause any trouble in day-to-day usage, but it does lead to a particular side effect: Bundler will generate an invalid Gemfile.lock.

Bundler, when generating the Gemfile.lock, uses the local cache and reads it directly, copying the version constraint into the file. However, when installing packages in a clean environment (a docker container or CI build server, for instance) bundler will compare the constraints in the Gemfile.lock against the Rubygems API. They must match exactly, but they don't, and so causes an error:

Downloading rb-inotify-0.10.1 revealed dependencies not in the API or the lockfile (ffi (~> 1.0)).
Either installing with `--full-index` or running `bundle update rb-inotify` should fix the problem.

I believe there was a bug with Rubygems that caused the specification to be saved incorrectly, that has since been fixed. Please rebuild the specification file using the latest version of Rubygems.

Full steps to reproduce:

1. Write a Gemfile that ends up with a dependency on rb-inotify. An example:
source "https://rubygems.org"
gem "middleman"
2. Install the inotify package from the repos: pacman -S ruby-rb-inotify
3. Build a lockfile for Rubygems: bundle
4. Observe that Gemfile.lock has the incorrect constraint: grep -C1 'inotify' Gemfile.lock
rb-inotify (0.10.1)
ffi (>= 1.0)
5. Reproduce the error above by using an empty environment: docker run --rm -it -v "$(pwd):$(pwd)" -w "$(pwd)" ruby:3.0 bundle install
This task depends upon

Closed by  Toolybird (Toolybird)
Thursday, 11 May 2023, 04:09 GMT
Reason for closing:  Won't fix
Additional comments about closing:  See PM's comments. The gemspec patching is included in the Arch Ruby packaging guidelines:
https://wiki.archlinux.org/title/Ruby_pa ckage_guidelines
Comment by Levente Polyak (anthraxx) - Monday, 05 July 2021, 20:05 GMT
we patch gemspec files to make them compatible with higher versions as pinned. ruby loves to keep non latest compatibility but our system repo packages aim for latest even tho upstream is compatible with latest. so this is a wont fix unfortunately and you need to create a namespaces ruby environment without system packages if you aim for 100% upstream equality for version constraints.
Comment by Nogweii (evaryont) - Monday, 05 July 2021, 23:42 GMT
Would you please reconsider that decision? The original constraint still allows ruby-rb-inotify to work with the latest ruby-ffi available. There is no guarantee that ruby-rb-inotify will work ruby-ffi 2.x; a major version bump would likely introduce backward incompatibilities. If it does work after the bump then why not submit a patch upstream? Until then, I feel like this is going to cause more breakage.

In the end, I guess I don't understand the benefit for this package. Bundler lock files generated on Arch will not be compatible with any other distro or with upstream Rubygems, and the Arch team will have the additional maintenance burden of supporting version combinations that the upstream authors don't. I don't see how that balances out.

Loading...