[Bug 268652] Qt5: Some apps fails to start after upgrading to 5.15.8

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #61 from Tomoaki AOKI <***@dec.sakura.ne.jp> ---
Just a FYI.

This problem resurrected by updating from
commit 59beb5740e59a6ae50fa6c0fc9c1079d744b9089
to
commit 100f2890786bdfa8df021654b530b0f749be46da
within which contains
commit f1f1a8be887ee2c5d75bec33cb8f8a89454e606b
that updates devel/icu to 73.1 and massive bumps,
including devel/qt5-core and www/qt5-webkit.

Strangely, this happened for updates using poudriere-built pkgs on stable/13,
amd64 but on main, amd64, which is updated using pkg_replace for both build and
install has no problem.

As before, finally, updating base helped on stable/13.
Other possible workarounds described in previous comments didn't help just as
before.

Possibly, some wrong infos are cleared and reconstructed on installworld?


As a record, this time, I've updated main environment by
pkg_replace -R devel/icu
pkg_replace -f devel/qt5-qmake devel/qt5-buildtools devel/autotoos\*
devel/libtool
pkg_replace -a
shutdown -r

I was planning, if the problem happenes, to forcibly updating qt5-*,
x11/libxkbcommon and *xcb*, but fortunately, these were not needed.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #62 from Tomoaki AOKI <***@dec.sakura.ne.jp> ---
(In reply to Tatsuki Makino from comment #59)

Sorry for looooong delay, but I've been stuck how I can confirm this myself.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #63 from Tatsuki Makino <***@hotmail.com> ---
I think it's a matter of checks like this one. -> bug 270389
It would mean that we would have to update from the qt port/package, which is
not affected by such a comparison.

And, there seems to be a tool to update FreeBSD packages by Qt, but I am
wondering what happened to those who were unable to use that tool due to a QT
version mismatch and went silent :) (bug 269929)

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #64 from Tatsuki Makino <***@hotmail.com> ---
There is an update to the current port tree that may cause this problem again
:)
In poudriere, the build was performed in the following order

qt5-qmake-5.15.10p156
qt5-buildtools-5.15.10p156
qt5-core-5.15.10p156
qt5-* (dbus, network, etc...)

qmake, buildtools and core were not built in parallel.
If problems occur, it may be necessary to investigate whether the above
sequence was followed.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #65 from Tomoaki AOKI <***@dec.sakura.ne.jp> ---
(In reply to Tatsuki Makino from comment #64)

Ah, thanks to the HEADS UP.
Fortunately, this time, I've not be bitten with this on stable/14, built using
poudriere-devel.

main, which I don't currently using (and not at all planning to using)
poudiriere[-devel], is not yet updated to the commit after and including qt5
upgrade.

Maybe I'll try poudriere[-devel] on main if it starts ignoring last 3 digits of
__FreeBSD_version (OSVERSION in ports framework) and leave it handled by each
ports.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #66 from Tomoaki AOKI <***@dec.sakura.ne.jp> ---
Forgot to post the result on main (not using poudriere, but pkg_replace on bare
metal environment).

The issue happened again here.
Forcibly rebuilt Qt components as Tatsuki described on comment #64 before
everything others.

Next, forcibly rebuilt known-to-be problematic and reproduced
audacious[-plugins], without luck. So as vlc. Ommitted libreoffice here, as
it't too large to test.

Rebuilt/reinstalled base. Without luck.

Forcibly rebuilt libxkbcommon, then, forcibly rebuilt Qt5 components again,
without luck.

What helped this time (not always helps, though) was to move *[Qq]t* under
/usr/local/lib/compat/pkg to other directory outside any of libpath.
audacious[-plign], vlc and libreoffice worked fine. Note that libreoffice is
not at all rebuilt (delayed updating).

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #67 from Tatsuki Makino <***@hotmail.com> ---
About the following
https://cgit.freebsd.org/ports/tree/Mk/Uses/qt-dist.mk#n255

PATCHDIR and FILESDIR are set from MASTERDIR, which is set from .CURDIR:tA.
If PORTSDIR is set and it differs from the .CURDIR prefix, these patches may
not apply.
If so, does make patch stop?

Is this relevant?

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #68 from Tomoaki AOKI <***@dec.sakura.ne.jp> ---
(In reply to Tatsuki Makino from comment #67)

In my case, both poudriere build on stable/14 and bare-metal build with
pkg_replace on main successfully applied patches.
No build failures on patch phase.

If I understand correctly, assuming ports tree are extracted into non-default
/ports/build/,

For Qt component FOO/qt5-BAR,
${PORTSDIR} is manually set as /ports/build (otherwise, basically,
/usr/ports is used)
${.CURDIR} is expanded as /ports/build/FOO/qt5-BAR

${.CURDIR} is the directory where the running make is invoked from unless
otherwise overridden by -C option.
Not the directory where the most-recently read (included) Makefile (or *.mk)
are read from.
So I think it should properly work.
Am I mis-understanding?

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #69 from Tatsuki Makino <***@hotmail.com> ---
(In reply to Tomoaki AOKI from comment #68)

${PORTSDIR} is manually set as /ports/build (otherwise, basically, /usr/ports is used)
${.CURDIR} is expanded as /ports/build/FOO/qt5-BAR

This means that if the value set in PORTSDIR is the same as the value at the
beginning of .CURDIR, there is no problem.
It was a check to see if the patch file shown in "make -C
/usr/ports/devel/qt5-qmake/ -V EXTRA_PATCHES" result could be reached.

... I have had a number of people here confirm what I have come up with
regarding possible matters.
So I tried to reproduce the procedure for updating from the old version to the
new version :)
The procedure is roughly as follows (but that may be wrong :) )

git revert --no-commit 2a5c778173f13a057551b4284269b82f6faa077f
poudriere bulk -j ... multimedia/vlc multimedia/audacious-plugin
ports-mgmt/pkg_replace
poudriere jail -s -j ...
jexec jailname-porttree-n env -i "TERM=$TERM" /usr/bin/login -f -p root
make -C /usr/ports/multimedia/vlc pkg-depends install-package
make -C /usr/ports/multimedia/audacious-plugin install-package
make -C /usr/ports/ports-mgmt/pkg_replace install-package
exit
git restore --source=HEAD --worktree --staged :/
jexec jailname-porttree-n env -i "TERM=$TERM" /usr/bin/login -f -p root
pkg_replace -B -a

This completed audacious, which did not start well :)
Errors like this.
ERROR ../src/libaudcore/plugin-load.cc:70 [plugin_load]:
/usr/local/lib/audaciou
s/General/albumart-qt.so could not be loaded: /usr/local/lib/libaudqt.so.2:
Undefined symbol "***@Qt_5"

This operation led to one clear difference between the package created by
poudriere and the update by pkg_replace.
The following unified diff.

--- /usr/local/lib/qt5/mkspecs/qmodule.pri 2023-09-25 23:38:37.000000000
+0000
+++
/usr/local/poudriere/data/.m/src-null-1/ref/usr/local/lib/qt5/mkspecs/qmodule.pri
2023-10-07 09:56:52.000000000 +0000
@@ -1,11 +1,13 @@
QT_CPU_FEATURES.x86_64 = mmx sse sse2
-QT.global_private.enabled_features = sse2 alloca_malloc_h alloca avx2 dlopen
network posix_fallocate reduce_exports reduce_relocations relocatable sql
system-zlib testlib xml
-QT.global_private.disabled_features = alloca_h android-style-assets
private_tests dbus dbus-linked gc_binaries gui intelcet libudev release_tools
stack-protector-strong widgets zstd
+QT.global_private.enabled_features = sse2 alloca_malloc_h alloca avx2 dlopen
libudev network posix_fallocate reduce_exports reduce_relocations relocatable
sql system-zlib testlib xml zstd
+QT.global_private.disabled_features = alloca_h android-style-assets
private_tests dbus dbus-linked gc_binaries gui intelcet release_tools
stack-protector-strong widgets
PKG_CONFIG_EXECUTABLE = pkgconf
QMAKE_LIBS_LIBDL =
+QMAKE_LIBS_LIBUDEV = -L/usr/local/lib -ludev
QT_COORD_TYPE = double
QMAKE_LIBS_ZLIB = -lz
+QMAKE_LIBS_ZSTD = -L/usr/local/lib -lzstd
CONFIG -= precompile_header
CONFIG += sse2 aesni sse3 ssse3 sse4_1 sse4_2 avx avx2 avx512f avx512bw
avx512cd avx512dq avx512er avx512ifma avx512pf avx512vbmi avx512vl
compile_examples f16c largefile rdrnd rdseed shani x86SimdAlways
QT_BUILD_PARTS += libs tools
-QT_HOST_CFLAGS_DBUS +=
+QT_HOST_CFLAGS_DBUS += -I/usr/local/include/dbus-1.0
-I/usr/local/lib/dbus-1.0/include

It seems that this is a file installed by qt5-qmake, but it looks like there
may be ports that should not be installed when it is built.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #70 from Tatsuki Makino <***@hotmail.com> ---
(In reply to Tatsuki Makino from comment #69)
Therefore...

Here is how to reproduce this problem

Either libudev-devd or zstd, or both, should be installed before building
qt5-qmake.
Build and install qt5-qmake.
Build and install qt5-core using this qt5-qmake.

Then, by doing the opposite, this problem is resolved.

Remove both libudev-devd and zstd.
Rebuild and install qt5-qmake.
Rebuild and install qt5-core using this qt5-qmake.
In some cases, rebuild and install qt5-widgets as well.

This may save you from rebuilding everything in qt5 :)

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #71 from Tatsuki Makino <***@hotmail.com> ---
I wrote like #70, but also remember the around comment #32.
#70 does not take into account the behavior when a large amount of garbage is
left in /usr/local/lib/compat/pkg.

It seems that pkg_replace does not include the behavior that if a library with
the same name exists, the one in compat/pkg is removed.
portmaster does its work.

Cannot mix incompatible Qt library (5.15.8) with this library (5.15.10)

If we get this message, we should check for it first :)

Then, Therefore, I will be destroying all the environments I have created to
reproduce this problem :)

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #72 from Tomoaki AOKI <***@dec.sakura.ne.jp> ---
(In reply to Tatsuki Makino from comment #70)

Thanks for digging into.

Maybe qmake somehow auto-detect alreay-installed files and automagically set
the options (features).
And QT_HOST_CFLAGS_DBUS differs, too.

Not sure it actually works, but is it possible to explicitly unset those 2
features on devel/qmake or Mk/Uses/qt[-dist].mk?

Mk/bsd.options.mk has description (comment) about ${opt}_QMAKE_ON and
${opt}_QMAKE_OFF, and following.

_ALL_OPTIONS_HELPERS= ${_OPTIONS_DEPENDS:S/$/_DEPENDS/} \
${_OPTIONS_DEPENDS:S/$/_DEPENDS_OFF/} \
${_OPTIONS_FLAGS:S/$/_OFF/} ${_OPTIONS_FLAGS} \
CABAL_FLAGS CMAKE_BOOL CMAKE_BOOL_OFF CMAKE_OFF
CMAKE_ON \
CONFIGURE_ENABLE CONFIGURE_OFF CONFIGURE_ON \
CONFIGURE_WITH IMPLIES MESON_ARGS MESON_DISABLED \
MESON_ENABLED MESON_FALSE MESON_OFF MESON_ON MESON_TRUE
\
PREVENTS PREVENTS_MSG QMAKE_OFF QMAKE_ON USE USE_OFF \
VARS VARS_OFF

But unlike cmake, mk/Uses/qmake.mk doesn't have descriptions about those.

FYI:
Looing for FreshPorts, libudev-devd and zstd are required by Qt6.
zstd is required by qt5-core. So they cannot blindly disabled, but limited to
qmake.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #73 from Tomoaki AOKI <***@dec.sakura.ne.jp> ---
(In reply to Tatsuki Makino from comment #71)

Of course. :-)

But in (hopefully) some rare cases, delete-from-ports softwares are mandatory.
For those cases, Old libraries which are mandatory (new one does not work for
them) and forced to be kept in /usr/local/lib/compat/pkg.

We can lock installed ports, but it is not desirable not to update common
libraries for some old locked ports.

It would be nice if there is any efficient tool to delete only really safe to
delete libraries from /usr/local/lib/compat/pkg.

FYI:
pkg_replace basically works as oldest port upgrading tool, portupgrade.
It keeps old libraries into /usr/local/lib/compat/pkg by default, unlike
portmaster.
This behaviour helps using applications in half-done state, some of required
libraries
are updated but others are not yet, for example, build failures.
Default of portmaster would be focus on security. But it assumes that...
*All ports are ALWAYS BUILT AND RUN SUCCESSFULLY, unless marked as BROKEN.
*ALL ports works 100% fine with old and updated ports.
that is not at all realistic assumption. portupgrade was much more realistic.
Unfortunately, portupgrade[-devel] is not well maintained for years,
so pkg_replace popped in and maintained well by current maintainer.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #74 from Tatsuki Makino <***@hotmail.com> ---
I was a little curious and tried a follow-up test, but could not reproduce
comment #69 through #71.
Perhaps they are wrong. Sorry.

And the workaround for this problem is to add the -u option to pkg_replace.
I just finished updating with pkg_replace -B -u -a, and in this case there is
no problem starting audacious, probably because /usr/local/lib/compat/pkg is
kept empty.

The next issue will describe the results of a more precise search for the cause
of the problem by reproducing it :)

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #75 from Tatsuki Makino <***@hotmail.com> ---
Created attachment 245540
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=245540&action=edit
unified diff of `grep / truss.log | grep -v ^poll`

(In reply to Tatsuki Makino from comment #74)

The difference between "pkg_replace -B -a" and "pkg_replace -B -u -a".
If -u was not used, the following files are backed up in /u*/l*/lib/compat/pkg.
Attached is a truss log that varies with and without the following set of
files.
^- is when there is a backup of the old library and ^\+ is when there is no
backup.
Are the next two lines worth noting?

-access("/usr/local/lib/lib/qt5/plugins",F_OK) ERR#2 'No such file or
directory'
+access("/usr/local/lib/qt5/plugins",F_OK) = 0 (0x0)

I guess this is a relative path following ../../lib/qt5 from dirname of
libQt5*.so*.
It seems that the failure of this has not even resulted in the subsequent
loading of the plugin.
It would then display "qt.qpa.plugin: Could not find the Qt platform plugin
...".

In the case of audacious, of the libraries that may contain code for this, the
file it is trying to load is /usr/local/lib/compat/pkg/libQt5Core.so.5, so
removing it is the quickest solution.

In the case of portmaster, it does not fundamentally back up the library unless
-w is used.
When the library is backed up using -w, the library of the same name is also
deleted in the following area.
https://github.com/freebsd/portmaster/blob/edb3fe64a9e1bd137045877e0981f49be1bf1a22/portmaster#L3893

====
From here down, only a list of backed up file names is available.

libQt5Core.so
libQt5Core.so.5
libQt5Core.so.5.15
libQt5Core.so.5.15.8
libQt5DBus.so
libQt5DBus.so.5
libQt5DBus.so.5.15
libQt5DBus.so.5.15.8
libQt5Gui.so
libQt5Gui.so.5
libQt5Gui.so.5.15
libQt5Gui.so.5.15.8
libQt5Multimedia.so
libQt5Multimedia.so.5
libQt5Multimedia.so.5.15
libQt5Multimedia.so.5.15.8
libQt5MultimediaGstTools.so
libQt5MultimediaGstTools.so.5
libQt5MultimediaGstTools.so.5.15
libQt5MultimediaGstTools.so.5.15.8
libQt5MultimediaQuick.so
libQt5MultimediaQuick.so.5
libQt5MultimediaQuick.so.5.15
libQt5MultimediaQuick.so.5.15.8
libQt5MultimediaWidgets.so
libQt5MultimediaWidgets.so.5
libQt5MultimediaWidgets.so.5.15
libQt5MultimediaWidgets.so.5.15.8
libQt5Network.so
libQt5Network.so.5
libQt5Network.so.5.15
libQt5Network.so.5.15.8
libQt5OpenGL.so
libQt5OpenGL.so.5
libQt5OpenGL.so.5.15
libQt5OpenGL.so.5.15.8
libQt5Qml.so
libQt5Qml.so.5
libQt5Qml.so.5.15
libQt5Qml.so.5.15.8
libQt5QmlModels.so
libQt5QmlModels.so.5
libQt5QmlModels.so.5.15
libQt5QmlModels.so.5.15.8
libQt5QmlWorkerScript.so
libQt5QmlWorkerScript.so.5
libQt5QmlWorkerScript.so.5.15
libQt5QmlWorkerScript.so.5.15.8
libQt5Quick.so
libQt5Quick.so.5
libQt5Quick.so.5.15
libQt5Quick.so.5.15.8
libQt5QuickParticles.so
libQt5QuickParticles.so.5
libQt5QuickParticles.so.5.15
libQt5QuickParticles.so.5.15.8
libQt5QuickShapes.so
libQt5QuickShapes.so.5
libQt5QuickShapes.so.5.15
libQt5QuickShapes.so.5.15.8
libQt5QuickWidgets.so
libQt5QuickWidgets.so.5
libQt5QuickWidgets.so.5.15
libQt5QuickWidgets.so.5.15.8
libQt5Sql.so
libQt5Sql.so.5
libQt5Sql.so.5.15
libQt5Sql.so.5.15.8
libQt5Widgets.so
libQt5Widgets.so.5
libQt5Widgets.so.5.15
libQt5Widgets.so.5.15.8
libQt5X11Extras.so
libQt5X11Extras.so.5
libQt5X11Extras.so.5.15
libQt5X11Extras.so.5.15.8
libQt5XcbQpa.so
libQt5XcbQpa.so.5
libQt5XcbQpa.so.5.15
libQt5XcbQpa.so.5.15.8
libcomposeplatforminputcontextplugin.so
libdeclarative_audioengine.so
libdeclarative_multimedia.so
libgstaudiodecoder.so
libgstcamerabin.so
libgstmediacapture.so
libgstmediaplayer.so
libibusplatforminputcontextplugin.so
liblabsanimationplugin.so
liblabsmodelsplugin.so
libmodelsplugin.so
libparticlesplugin.so
libqbsdfb.so
libqbsdkeyboardplugin.so
libqbsdmouseplugin.so
libqevdevkeyboardplugin.so
libqevdevmouseplugin.so
libqevdevtabletplugin.so
libqevdevtouchplugin.so
libqgenericbearer.so
libqgif.so
libqico.so
libqjpeg.so
libqminimal.so
libqmldbg_debugger.so
libqmldbg_inspector.so
libqmldbg_local.so
libqmldbg_messages.so
libqmldbg_native.so
libqmldbg_nativedebugger.so
libqmldbg_preview.so
libqmldbg_profiler.so
libqmldbg_quickprofiler.so
libqmldbg_server.so
libqmldbg_tcp.so
libqmlfolderlistmodelplugin.so
libqmllocalstorageplugin.so
libqmlplugin.so
libqmlsettingsplugin.so
libqmlshapesplugin.so
libqmlwavefrontmeshplugin.so
libqoffscreen.so
libqquicklayoutsplugin.so
libqtaudio_alsa.so
libqtmultimedia_m3u.so
libqtqmlstatemachine.so
libqtquick2plugin.so
libqtuiotouchplugin.so
libqvnc.so
libqxcb-egl-integration.so
libqxcb-glx-integration.so
libqxcb.so
libsharedimageplugin.so
libwindowplugin.so
libworkerscriptplugin.so

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #76 from Tatsuki Makino <***@hotmail.com> ---
There is an update to the current port tree that may cause this problem again
again :)

The existence of libudev-devd and zstd makes a difference in what qmake
installs, but is not relevant to this problem.
Thus, there is absolutely no need to delete them when updating.

When updating, do not perform operations that break the order as noted in
comment #64.
This would work well if done automatically.

When updating to avoid this problem, use -u option for pkg_replace.

To reproduce this problem, update by pkg_replace without -u option.
After confirming that the problem reproduces, also confirm that the problem is
resolved by deleting the following files.

/usr/local/lib/compat/pkg/libQt5Core.so.5
/usr/local/lib/compat/pkg/libQt5*.so.5


The following is unrelated.
I sometimes delete files in /usr/local/lib/compat/pkg with the following
command.

find -L -d -s -x -- /usr/local/lib/compat/pkg/ \( -type d -empty -or -type l
-or -not -type d -atime +4w \) -exec rm -i -r -v -- {} \;

This is exactly what I am using, but in this case even the directory of
...lib/compat/pkg is deleted, so -mindepth 1 may be necessary :)

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #77 from Tomoaki AOKI <***@dec.sakura.ne.jp> ---
(In reply to Tatsuki Makino from comment #76)

Thanks for heads-up.
This time, fortunately, I've not bitten.

For the record, what I've performed this time (after updating ports tree) are:

For stable/14 poudriere build (to be paranoid):
*Fetch distfiles with `pkg_replace -a -c -m 'WITH+="NVIDIA,NVIDIA_GL" \
DISABLE_VULNERABILITIES=yes' -F -k`
*Build qt5-qmake with `poudriere bulk -j jailname -J 6 -S devel/qt5-qmake`.
*Build qt5-buildtools with `poudriere bulk -j jailname -J 6 -S \
devel/qt5-buildtools`.
*Build qt5-core with `poudriere bulk -j jailname -J 6 -S devel/qt5-core`.
*Created list of remaining Qt5 components as /poudriere/pkglist.qt5.
*Build remaining Qt5 components with `poudriere bulk -f
/poudriere/pkglist.qt5 \
-j 14amd64 -J 6 -S`.
*Single port (sorry, forgot to take memo) failed complaining
graphics/vulkan-loader
is missing (maybe poudriere missed the dependency, although it was deleted
before
actual builds were started), so built it like others.
*Redo remaining Qt5 components builds.
*Build all other updated ports as usual.

For main pkg_replace build:
*Update qt5-qmake with `pkg_replace -c -v -m 'DISABLE_VULNERABILITIES=yes' \
-u -b devel/qt5-qmake`.
*Update qt5-buildtools with `pkg_replace -c -v -m
'DISABLE_VULNERABILITIES=yes' \
-u -b devel/qt5-buildtools`.
*Update qt5-core with `pkg_replace -c -v -m 'DISABLE_VULNERABILITIES=yes' \
-u -b devel/qt5-core`.
*Update remaining Qt5 components with `pkg_replace -c -v \
-m 'DISABLE_VULNERABILITIES=yes' -u -b qt5-\*`.
*Update everything else as usual.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #78 from Tomoaki AOKI <***@dec.sakura.ne.jp> ---
(In reply to Tatsuki Makino from comment #76)

Comment for this separately. :=)

Post by b***@freebsd.org
The following is unrelated.
I sometimes delete files in /usr/local/lib/compat/pkg with the following command.
find -L -d -s -x -- /usr/local/lib/compat/pkg/ \( -type d -empty -or -type l -or -not -type d -atime +4w \) -exec rm -i -r -v -- {} \;

This time, I've moved Qt5-related remnants in /usr/local/lib/compat/pkg
manually, so not tested, but what about below limited to Qt* components?

find -L -d -s -x -- /usr/local/lib/compat/pkg/ \( -type d -empty -or -type l
-or -not -type d -atime +4w \) -iname \*qt\* -exec rm -i -r -v -- {} \;

Or if deletion is not wanted and /usr/local/lib/compat/pkg.qt5 is not in
library path,

find -L -d -s -x -- /usr/local/lib/compat/pkg/ \( -type d -empty -or -type l
-or -not -type d -atime +4w \) -iname \*qt\* -exec mv -i -v {}
/usr/local/lib/compat/pkg.qt5 \;

would work, if I understand man pages correctly.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #79 from Tatsuki Makino <***@hotmail.com> ---
(In reply to Tomoaki AOKI from comment #77)

This time, as the saying "百聞は一見に如かず" says, I gave advice based on my own
experience, so I am glad that I did not have any problems.

The build order of qt5-qmake, qt5-buildtools, and qt5-core was followed, so
there should be no "Cannot mix incompatible Qt library (5.15.x) with this
library (5.15.y)" failures.

Since the -u option was used for pkg_replace, there will be no failure to
'qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""'.
However, this time, the old version of backup does not exist.

(In reply to Tomoaki AOKI from comment #78)

Since this find is for the question of when to delete the backed up library,
there is no need to modify it.
For example, run the following ls

ls -ATlrtu -- /usr/local/lib/compat/pkg/

total 1088
-rwxr-xr-x 1 root wheel 485264 Sep 21 07:05:17 2023 libsodium.so.26
-rwxr-xr-x 1 root wheel 550288 Oct 12 07:30:11 2023 libimagequant.so.0

In the case of portmaster, the backup will be as shown above.
If this is older than the time of startup,

sysctl -n kern.boottime

{ sec = 1691537044, usec = 941220 } Wed Aug 9 08:24:04 2023

daemons that run at the same time as startup are not affected and can be
removed.
If the time is updated close to the current time, then the library is still
linked to something.
Problem binaries are relatively easy to find with pkg check -dna.
If the problem is not found by it, it is rather tricky :)

This find is a somewhat automated version of deleting backup libraries that
have not been accessed for a certain period of time.
However, since rm has a -i option, it is manual to some extent :)
The -s option in find is to make the order somewhat understandable, and the -x
option is to avoid hassle if something like crossing mount points is backed up.
Then remove the libraris and etc. under 3 conditions.
"find -d ... -type d -empty" immediately deletes empty directories. I think
-mindepth 1 is necessary because it also deletes the pkg directory when the
contents are completely empty :)
"find -L ... -type l" deletes unpointed symlinks. The -L option treats symlinks
whose target is not a symlink as non-symlink.
"find ... -not -type d -atime +4w" is deleting anything other than directories
that haven't been accessed in over 4 weeks.

I think the libraries backed up to ${LOCALBASE}/compat/pkg are still to rescue
binaries linked to the old library, not to roll back when bugs exist in the new
library.
So, if pkg_replace is used that does not implement the function to delete a
library of the same name from backup, such as portmaster written in comment
#75, it should be done manually immediately.
Rather than creating a command or tool that can be done in one shot, it is a
function that should be implemented on pkg_replace side depending on the backup
philosophy.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

Mark Linimon <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Assignee|ports-***@FreeBSD.org |***@FreeBSD.org
Flags| |maintainer-feedback?(***@Fr
| |eeBSD.org)

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

Bessie Shea <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #80 from Bessie Shea <***@gmail.com> ---
That's nice!

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

Ken DEGUCHI <***@sz.tokoha-u.ac.jp> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@sz.tokoha-u.ac.jp

--- Comment #81 from Ken DEGUCHI <***@sz.tokoha-u.ac.jp> ---
(In reply to Tatsuki Makino from comment #79)

I received an email from Dmitry.

I will try to fix it so that pkg_replace does not save the old library when the
old and new libraries have the same name. It will take some time.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268652

--- Comment #82 from Ken DEGUCHI <***@sz.tokoha-u.ac.jp> ---
(In reply to Ken DEGUCHI from comment #81)

Fixed pkg_replace was released.
https://github.com/kdeguchi/pkg_replace/releases/tag/20240514

I have created a patch to the ports tree. See bug #278978.

Thanks.