[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 #41 from deivid.rodriguez@riseup.net ---
Thanks for your comment. I'll reply to what concerns me.

>   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

I'm sorry someone replied to an email to you rudely at the time. Anyways, I'm
trying to help out now so let's move on, yeah? The issue you linked to and a
few others have been fixed by the different patches merged recently, and
rubygems should no longer try to write outside of `--destdir` if it's passed
(both during normal operation or binstub/plugin regeneration).

> 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.

They absolutely do! In fact, binstub regeneration is an important feature of
rubygems upgrader. We sometimes need to tweak the binstubs that rubygems
generates. Having rubygems upgrader automatically upgrade all binstubs to the
new format a new rubygems version needs and generates is really nice. Even when
first installing rubygems, I could imagine situations where upgrading binstubs
in an exisiting gem path could be handy. In any case, it's great that you don't
need that yourselves, I'm happy I merged the main fix and reticketed that
little issue for later.

> 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).

I'm sorry the introduction of those flags broke things for you. That doesn't
mean the flags themselves are backwards incompatible, actually quite the
opposite, they were introduced to fix backwards compatibility issues with new
rubygems versions. Unfortunately in this case, their introduction was buggy
since they didn't play well with `--destdir`. So I think a more reasonable
request would be: don't introduce new bugs with new features or bug fixes xD.
That's our goal but you know, shit happens. Anyways, when I make changes that I
think could possibly affect/break packagers I usually ping at least Debian &
Fedora packagers to gather opinions. I'm happy to add someone from FreeBSD to
my "rubygems packagers ping list" if you wish. I'm aware you're not happy about
past upstream maintenance, and that upstream has never paid too much attention
to packagers (they are a minority of our users, and upstream could barely deal
with the rest of our community), but I'm trying to help more now, so let's move
on and not talk about the past, specially since I wasn't really involved back
then. Ok?

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