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