Date: Sun, 05 Dec 2021 18:13:47 +0000 From: bugzilla-noreply@freebsd.org To: ruby@FreeBSD.org Subject: [Bug 258108] [exp-run] devel/ruby-gems: Update to 3.2.30 (Fixes for Ruby 3.0) Message-ID: <bug-258108-21402-7ROwl3ECNI@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-258108-21402@https.bugs.freebsd.org/bugzilla/> References: <bug-258108-21402@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258108 --- 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 t= he new format a new rubygems version needs and generates is really nice. Even = when first installing rubygems, I could imagine situations where upgrading binst= ubs in an exisiting gem path could be handy. In any case, it's great that you d= on'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 n= ew 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 x= D. That's our goal but you know, shit happens. Anyways, when I make changes th= at 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 a= bout past upstream maintenance, and that upstream has never paid too much attent= ion to packagers (they are a minority of our users, and upstream could barely d= eal 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 ba= ck then. Ok? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-258108-21402-7ROwl3ECNI>