On 06/17 02:24, Stuart Henderson wrote:
> 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).
I committed the ruby default version change. Thank you for reviewing.
I would be fine changing ruby-libmarisa to libmarisa-ruby to work around
that issue, similar to how weechat handles it. I left libmarisa's
package names alone during the update.
I'm against having ruby- prefixed packages that are Ruby
version-dependent. That being said, if another developer wants to change
the rubyXY- prefix to ruby- for non-gem ports, I don't object.
If users do run into a problem where an old rubyXY- package causes
problems during upgrading, pkg_delete rubyXY-foo and pkg_add rubyXZ-foo
should solve it easily. I haven't seen reports of problems from users
doing that, so I assume at least one of the following is true:
1. nobody has problems
2. nobody cares to report the problems
3. nobody uses the packages
4. users can fix the issues themselves
Best,
Jeremy
