darkgeek
As far as I can see, this happens whenever LANG_VERSION_DEFAULT and LANG_VERSION_REQD are changed in the pkgsrc infrastructure, or LANG_VERSIONS_ACCEPTED is changed inside a package Makefile. "LANG" may be anything among LUA, PYTHON, RUBY, PGSQL and PHP.
Apparently pkg_rolling-replace has trouble upgrading packages with a PKGNAME of fooNN-bar and a PKG_PATH of category/foo-bar.
In this case, it keeps reporting a mismatch for lua52-BitOp even if it's installed because it doesn't see lua52-BitOp as a valid replacement for lua51-BitOp, installed through devel/lua-BitOp (which according to pkg_chk however, required a make replace and was therefore flagged as a mismatched package by pkg_admin). Remember that pkg_rolling-replace uses pkg_chk to do determine which packages need to be rebuilt, and that pkg_chk in return writes the results to the package database, via pkg_admin.
From what we know the default version for Lua hasn't changed (it's been lua54 for a while). However, looking at lua-BitOp Makefile, I see it asks for lua52 or lua51(LUA_VERSIONS_ACCEPTED= 52 51), preferring lua52 first. It's possible that you had previously installed something strictly requiring lua51(an example is editors/neovim), so that other packages accepting both 51 and 52, and finding lua51 used the latter (influencing the lua version used by packages depending on them as tools). Now that such package doesn't exist any more on your system,
lua-BitOp silently pulls its preferred Lua version.
You may fix this using pkg_chk:
$ pkgin autoremove
$ pkg_chk -g (creates a database of installed packages at /usr/pkgsrc/pkgchk.conf)
$ pkg_chk -a -u -s -L /var/log/pkgchk.$(date +'%Y%M%d%H%m%S').log
pkg_chk looks for mismatched packages, generates a list of packages to rebuild/update and dependencies to add, then removes all packages requiring a make replace / make update, and starts rebuilding them from scratch. This avoids the naming mismatch issue.
If this doesn't work, you can try to recursively remove the mismatched packages first:
$ pkg_chk -rn
$ pkg_chk -r
This is a destructive approach as it removes mismatched packages without keeping track of what was installed first (needed for later upgrade, which is what pkg_chk normally does), but may help getting rid of the problematic packages.
As an alternative, you can manually remove all the lua51- packages, and reinstall them manually after pkg_rolling-replace completes the update. You can also use the -k option to pkg_rolling-replace to keep going even after a package replace fails. At the end of the build, you'll be presented with a list of failed packages to take care of.
Last, but not least, there's also the dirty trick of masking problematic packages with pkg_admin set mismatch=NO and pkg_admin set rebuild=NO (after which you'll need to run pkg_rolling-replace without the pkg_chk backend).
