From: Stuart Henderson Subject: Re: Switch default ruby version in ports from 3.4 to 4.0 To: Jeremy Evans Cc: OpenBSD ports Date: Wed, 17 Jun 2026 02:24:02 +0100 On 2026/06/16 17:20, Jeremy Evans wrote: > On 06/16 10:54, Stuart Henderson wrote: > > On 2026/06/15 23:58, Jeremy Evans wrote: > > > I would like to update the default ruby version in ports from 3.4 to > > > 4.0. I think this is a good time in the release cycle for this change. > > > > yes. > > > > > Other than ruby.port.mk, most changes needed are REVISION bumps. > > > Exceptions: > > > > > > * databases/xapian-bindings: Needs PLIST changes due to rdoc changes in > > > ruby 4.0 (no bump as package prefix changes to ruby40) > > > * sysutils/ruby-pdk: gem metadata needs a patch change to build Ruby 4.0 > > > version. > > > * textproc/redland-bindings: Drop REVISION-ruby, as the package prefix > > > changes, this doesn't need a REVISION bump. > > > > > > During this process, I saw we have textproc/libmarisa that uses a ruby- > > > prefix. That seems like a bug. We should switch to a > > > ruby${MODRUBY_BINREV}- prefix. We used to warn for ruby- prefixes, but > > > that was removed in a quirks change a while back. > > > > I think that might be alright in this case although it does result in > > leaving something fragile in the tree. > > > > Problem is that with the rubyXY- prefix, unless you provide an upgrade > > path via quirks (which I think you decided to skip doing in general for > > ruby), you leave an installed old package with whatever dependencies > > it has. If that were to result in a conflict (i.e. if the old installed > > package RUN_DEPENDS on a specific version of another port) it would > > break pkg_add updates. > > > > (I think this is ok via LIB_DEPENDS because of the .libs-* mechanism). > > > > Are there benefits to using rubyXY- prefixes (instead of just ruby-) > > for these ports which can't support multiple ruby versions in parallel > > anyway that would make it worth the risk? > > Without rubyXY-, you have no indication of what ruby version the package > targets. Most of the ports we are discussing here provide extensions > specific for a ruby version, it makes sense to treat them as we would > treat a ruby gem port, since they are functionally similar. > > > (i.e. I'd prefer to go in the other direction and change those rubyXY- > > prefixes to just ruby-).. > > That would not be my preference. I'm willing to accept a ruby- prefix > if there is an actual conflict (e.g. rubyXY- and rubyXZ- packages would > conflict), but even there I would prefer to remove the conflicts if > possible. > > For libmarisa, the ruby package is a single ruby version-specific file: > > $ cat textproc/libmarisa/pkg/PLIST-ruby > @so ${MODRUBY_SITEARCHDIR}/marisa.so > > This shouldn't conflict when the ruby version changes. It's true that > pkg_add doesn't automatically switch from rubyXY- to rubyXZ-, but that's > just like most other Ruby ports. There shouldn't be a problem with the > rubyXY- and rubyXZ- packages being installed at the same time. > Eventually, when support for old Ruby version is removed, quirks will > warn about the package, and a user who forgot to remove it earlier is > reminded to remove it at that point. these quirks warnings are not enough to fix updates if there's a dependency conflict. indeed, it might not be possible to successfully complete the update that includes the newer version of the quirks package that has the warning... most of the common rubyXY- ports only end up depending on other things in the ruby ecosystem and you're not likely to run into a problem there. > I understand there is a hypothetical issue of a port that conflicts due > to dependencies and not files, but unless we actually have that > situation, I don't think we should worry about it. indeed, it's about dependencies, not packages. it's especially a problem where Python is involved as the whole set of those packages need to be updated as a huge set where there's a 3.x->3.y type bump. (when we've had problems like this in the past, some of them have been pretty difficult to solve after the fact). the sort of ports where a problem would be most likely to show up are ruby extensions pulling in C software (e.g. ruby-rmagick, redland-bindings, rrdtool), especially if that software pulls in glib2/similar. I don't know whether it is hypothetical without testing. (that would involve installing on e.g. 7.9 release or earlier, updating to -current, and running pkg_add -u against a package dir that has update candidates for all the installed packages except the relevant rubyXY- packages). I suppose that could be tested after committing though. What we really don't want is for users to hit problems due to this and then wave chainsaws around trying to fix their package db if they do run into problems. (One example that would be a problem is net/weechat; a user who has both ,-ruby and ,-python installed absolutely relies on there being an upgrade path, so if the PKGNAME there were to change from weechat-ruby to rubyXY-weechat it would definitely break updates). > The only ruby-* packages in the ports tree are for the supported Ruby > versions, libmarisa (which I think is a mistake as the package is > Ruby version-dependent), and ruby-shims (which I think is fine as it > is a Ruby version-independent tool). > > > Index: www/webkitgtk4/Makefile > > > =================================================================== > > > RCS file: /cvs/ports/www/webkitgtk4/Makefile,v > > > diff -u -p -u -p -r1.259 Makefile > > > --- www/webkitgtk4/Makefile 2 Jun 2026 09:09:28 -0000 1.259 > > > +++ www/webkitgtk4/Makefile 16 Jun 2026 06:42:00 -0000 > > > @@ -16,7 +16,7 @@ DISTNAME = webkitgtk-${V} > > > PKGNAME = webkitgtk${API:S/.//}-${V} > > > FULLPKGNAME = ${PKGNAME} > > > > > > -REVISION = 0 > > > +REVISION = 1 > > > > > > EXTRACT_SUFX = .tar.xz > > > SUBST_VARS = API > > > > In webkitgtk4, it looks like ruby is only used during the build to > > generate some files and ruby-specific information doesn't make it into > > packages, so this probably doesn't need a bump. This matters because > > when updates are backported to -stable, which is very likely for > > webkitgtk, the REVISION bump would need to be maintained. So I think > > it would be better to skip that bump. (Alternatively add a "keep > > package version above 7.9-stable" comment next to the REVISION in -current). > > Thank you, I dropped this hunk. > > > > --- editors/vim/Makefile 15 Jun 2026 20:10:30 -0000 1.309 > > > +++ editors/vim/Makefile 16 Jun 2026 06:23:57 -0000 > > > @@ -4,6 +4,7 @@ COMMENT= vi clone with many additional f > > > # if there are new languages for manpages, "make fix-plist" will add the > > > # ${GUI_ONLY} markers as needed for gui-only tools. > > > V= 9.2.0653 > > > +REVISION= 0 > > > > similar, except this bump definitely is needed, so please add a > > "# keep package version above 7.9-stable" comment. > > I added that comment. > > OKs? I think so ..