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

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

--- Comment #79 from Tatsuki Makino <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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.