Re: Switch default ruby version in ports from 3.4 to 4.0

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