From: Jeremy Evans Subject: Re: Switch default ruby version in ports from 3.4 to 4.0 To: OpenBSD ports Date: Tue, 16 Jun 2026 17:20:04 -0700 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. 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. 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? Best, Jeremy