From: Stuart Henderson <stu@spacehopper.org>
Subject: Re: Switch default ruby version in ports from 3.4 to 4.0
To: Jeremy Evans <jeremy@openbsd.org>
Cc: OpenBSD ports <ports@openbsd.org>
Date: Tue, 16 Jun 2026 10:54:57 +0100

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?

(i.e. I'd prefer to go in the other direction and change those rubyXY-
prefixes to just ruby-)..

> Tested on amd64 using a bulk of all ports that depend on a ruby port.
> This has fewer bumps than previous upgrades. I decided not to bump
> ports where MODRUBY_RUNDEP=No, unless SUBST_VARS indicated something
> ruby related. These tended to be ports using ruby during build or test,
> where the change in Ruby version shouldn't affect the package.
> 
> OKs?

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

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