[Bug 258108] [exp-run] devel/ruby-gems: Update to 3.2.30 (Fixes for Ruby 3.0)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258108

--- Comment #40 from Thibault Jouan <tj+freebsd_ports@a13.fr> ---
About updating/committing a patch:

  The issue here as I understand, is that once a patch is attached we
have to check it with exp-run, then wait for review, approval and
commit it (Comment #34). But understandably, the exp-run and
adjustments on the patch take some time, reviewing it too, and by this
time some gem ports affected by the patch have been updated.

  I'm happy to update the patch as many time as needed but:
* I don't want to give unnecessary work to people (Antoine Brodin for
  exp-run for example);
* I don't have a workstation with the availability and build power to
  rebuild *all* ports depending on RubyGems fast enough before the gem
  ports get updated (I mean trying to do exp-run on my machine is not
  really possible event if I limit ports to the ones depending on
  RubyGems).

  Anyway I will make a new update, but not before one or two days at
least. In the meantime, if you don't use any of the gems where the
FreeBSD port patched the gem specification file, then you can ignore
the failure and keep the version currently in the port tree. It won't
affect devel/ruby-gems itself, nor any gem installed with `gem install
...`.

  This is slightly unrelated, but a thing that could help is to get
rid of those gem specification patches. Just an idea but ideally,
maintainers of the FreeBSD port could convince gem author to fix
version specifications in dependencies, so that we wouldn't need
patches in the port (I'm pretty sure it was done, but don't know to
which extent). I also know that a dedicated feature for this was
discussed upstream (to avoid patching), but IIRC wasn't very popular
(because ideally gems should be fixed directly).


About RubyGems setup command `--destdir' and
`--no-regenerate-binstubs' options (Comment #36 and Comment #38):

  The original issue regarding executable wrappers in combination with
`--destdir' is from RubyGems 2.7.0 if I'm correct (909b5fb8). I
reported it by mail with a possible fix to the author, but got a rude
answer at the time. It was later possible to workaround this with
4619f13a, we have to pass `--no-regenerate-binstubs' explicitly. This
is similar to the more recent `--no-regenerate-plugins' and
`--format-executable' which we must now pass explicitly to the setup
command for success. One of the places where this was discussed later
is here: https://github.com/rubygems/rubygems/issues/2370

  With a normal installation of RubyGems, there cannot be any
executable wrapper to rewrite (or any plugin wrapper) since we need
RubyGems to install gems, so it happens before we could have a gem
installed. The kind of manual update that was explained in the GitHub
issue, or shown with rake gem in Comment #38 only affects some
RubyGems developers and maintainers if I understand correctly, and
only when "experimentally" installing RubyGems manually over an
existing installation. End users should never encounter this scenario.

  I only noticed it (years ago) because of the behavior being the
default, while attempting to update the port, because the name of the
environment variable to enable bundler changed, and because the build
system was warning about things not installed where they should be.
The conditions to trigger it are very specific. IMO all people
maintaining RubyGems ports introduced `--no-regenerate-binstubs' in
their build at the time, and wont use the code path where that last
remaining bug may be. What would help is if following similar features
were "opt-in" instead of "opt-out" (I guess we cannot change actual
ones in 3.x again, to avoid breakage).

-- 
You are receiving this mail because:
You are the assignee for the bug.