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