Bug 259660 - Package Rules Not Following FreeBSD Base Dependencies Causing Major Mess of Mixed Versions of Ports Libraries to be Installed on System Rendering Various Ports Non-Functional
Summary: Package Rules Not Following FreeBSD Base Dependencies Causing Major Mess of M...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Port Management Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-05 14:04 UTC by John
Modified: 2024-01-05 07:34 UTC (History)
7 users (show)

See Also:


Attachments
20211105 13:43 Current State of QT Package Versions via pkg update for 18 months (2.15 KB, text/plain)
2021-11-05 15:31 UTC, John
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John 2021-11-05 14:04:24 UTC
This bug is ongoing for over a year and of latest of number intervening updates as of 05 November 2021.

xpdf failed with error "Cannot mix incompatible Qt library (5.14.2) with this library (5.15.2)".

Starting over a year ago xpdf failed with error "Cannot mix incompatible Qt library (5.14.2) with this library (5.15.0)".
Comment 1 Cy Schubert freebsd_committer freebsd_triage 2021-11-05 14:44:03 UTC
I'm not able to reproduce the problem here using qt5-core-5.15.2_6 and xpdf4.

Can you please rebuild and reinstall the port and report back if that fixes the problem.
Comment 2 John 2021-11-05 15:03:08 UTC
(In reply to Cy Schubert from comment #1)
I have updated system several times since this first occurred after the August 2020 update and updates since.  The problem persists. graphics/xpdf is not the only application that has this QT library issue.  There is clearly something wrong with the manner the packages using these QT libraries are being built that needs to be fixed.  I just do not know what details are needed to determine why the QT libraries have mixed  5.14.x and 5.15.x versions that clearly the pkg update is not dealing with updating otherwise there would not be a mix of 5.14.x and 5.15.x QT libraries.
Comment 3 Cy Schubert freebsd_committer freebsd_triage 2021-11-05 15:17:34 UTC
I assume by update the system you mean pkg upgrade, correct?
Comment 4 John 2021-11-05 15:31:58 UTC
Created attachment 229294 [details]
20211105 13:43 Current State of QT Package Versions via pkg update for 18 months

Console snip of QT packages installed on system via pkg as of 20211105 13:43
Comment 5 John 2021-11-05 15:32:32 UTC
(In reply to Cy Schubert from comment #3)
Correct, pkg upgrade.

I have added snip of output automatically created by my system scripts that clearly shows the mess of mixed versions of QT libraries.  I can if you wish post the state of the QT libraries prior to the problem update of August 2020.
Comment 6 Cy Schubert freebsd_committer freebsd_triage 2021-11-05 16:12:02 UTC
The problem is some of your qt5 packages are out of date: qt5-widgets, qt5-gui, qt5-printsupport, qt5-network, and others. You will be able to see the extent of the problem with,

pkg info -d xpdf | awk 'NR > 1 {print}' | xargs pkg info

Notice that the qt5-* packages listed are out of date.

To fix this,

pkg info -d xpdf | awk 'NR > 1 {print}' | xargs pkg info -o | awk '{print $2}' | xargs pkg upgrade -f

Failing that, you will need to reinstall all your packages from scratch (which can be done using a series of pkg commands which I can show you if you need them).

Now, if some of your qt5 packages are mysteriously out of date, could others be? Even after fixing this you may find other packages misbehaving because of the same problem.

Also note: some of your packages may be uninstalled because they are no longer supported. Allow them to uninstall. If not, I cannot help you.
Comment 7 John 2021-11-05 17:31:00 UTC
(In reply to Cy Schubert from comment #6)

The output of "pkg info -d xpdf | awk 'NR > 1 {print}' | xargs pkg info" is:

2021-11-05 14:38:18+0000 UTC 1636123098 ~ $ pkg info -d xpdf | awk 'NR > 1 {print}' | xargs pkg info
qt5-widgets-5.14.2
qt5-gui-5.14.2
qt5-printsupport-5.14.2
gsfonts-8.11_8
freetype2-2.10.4
cups-2.3.3op2
qt5-network-5.14.2
qt5-svg-5.14.2
png-1.6.37_1
qt5-core-5.15.2_5
qt5-concurrent-5.15.2_2
desktop-file-utils-0.26
2021-11-05 16:47:46+0000 UTC 1636130866

The bug description should remain as listed as that was the exact issue.  By changing with the wording that removes the key element of " Cannot mix incompatible Qt library" prevents others from finding.

Second this is not a weird nor local problem.  Clearly when one follows the FreeBSD updates process it did not do what it was supposed to do nor did the updates detect the obvious as I noted mixed versions of QT libraries.  Just because you cannot duplicate the issue does not define is as a local problem when all updates on the system have used the FreeBSD pkg update/upgrade process and were never bypassed at all.  Many bugs fixed even in FreeBSD base many never experience, but that does not mean the bugs fixed are local nor weird.

The "fix" is not a fix, but work around.  Once that is done there will be no way to determine what the actual problem case and bug(s) that cause the issue.  That means the issue can occur again and/or the underlying issue can case similar issues with other subsystems that are broken into smaller packages so they are not ware of their dependence on each other.  This issue is clearly package dependency issue.  How else could a system ever have such a mess of mixed versions of QT libraries.  I suspect I was not only one with this issue, but I suspect what was done instead of fixing the issue was people just manually did "something" to make it go away and not report nor try to fix.

Would it not make more sense to find the root cause and fix the root cause of the problem rather than wipe out any trace of finding the problem so will not occur again.

I do not see why it is necessary to reinstall packages that are not QT related when the problem is clearly when pkg did updates for certain QT packages it did not updates all QT packages to same version which is at the heart of this issue.  an issue I have lived with for 18 months hoping would somehow correct itself.

Clearly the system knows what QT packages and their versions are for xpdf, and yet the pkg system does not know that it has mixed versions of QT packages when obviously that is not correct and will not work using mixed versions of QT packages.
Comment 8 Cy Schubert freebsd_committer freebsd_triage 2021-11-05 17:48:42 UTC
You fail to understand. This is not an xpdf problem and cannot be fixed by patching it. Your computer has qt 5.14.2 and qt 5.15.2 packages installed. They will not work together.

The problem is that at some point when you performed a pkg upgrade that it didn't upgrade all your packages. It may be that your local catalogue is corrupted in some way and that a package update -f might resolve your problem.

The root cause is that at some point pkg upgrade failed to completely update your packages.

You can either follow the advice to resolve the root cause or you can cd /usr/ports/graphics/xpdf && make deinstall install to work around the problem to build a custom xpdf for your computer (only) that uses the mixed libraries. Failure to either fix the local problem (or implement the workaround in this paragraph) leaves you in an unsupported state.

Mixed versions of qt5 packages installed is unsupported and libraries xpdf is calling are complaining to notify you of the mismatch. This notification to tell you that you have mixed qt5 versions installed is working as intended.
Comment 9 John 2021-11-05 18:59:23 UTC
(In reply to Cy Schubert from comment #8)

I am not failing to understand.  The proposed "fix" that is really a very limited workaround for the mess of incompatible QT package versions is limited as only will fix xpdf and no other packages affected by the incompatible mess of QT versions.  A workaround that only deals with the incompatible QT package mess affecting xpdf that is only subset of incompatible mixed mess of QT package versions issues that happens to affect xpdf as I am understanding your findings.  There are far more incompatible versions of QT packages than used with xpdf which means there would still be a number of incompatible versions of QT packages. This means still many mixed release of incompatible QT packages would still exist with the "fix" proposed after the "fix" workaround.  The number of incompatible mixed versions of QT packages that would still remain with the proposed "fix" that is really a very limited workaround and does not address the underlying cause of incompatible mix versions of QT packages for 18 months.

I took your suggested commands to list packages for two QT 5.15.x packages that were updated about 18 months ago just to illustrate a point:

2021-11-05 16:50:15+0000 UTC 1636131015 ~ $ pkg info -d qt5-core-5.15.2_5 | awk 'NR > 1 {print}' | xargs pkg info
etc_os-release-0.1_3
qtchooser-66_4
pcre2-10.37
icu-69.1,1
glib-2.66.8,2
gettext-runtime-0.21
double-conversion-3.1.5.19
zstd-1.5.0
2021-11-05 17:39:32+0000 UTC 1636133972 ~ $ pkg info -d qt5-dbus-5.15.2_1 | awk 'NR > 1 {print}' | xargs pkg info
qtchooser-66_4
qt5-core-5.15.2_5
dbus-1.12.20_5
2021-11-05 17:40:10+0000 UTC 1636134010 ~ $ pkg info -d qt5-widgets-5.14.2 | awk 'NR > 1 {print}' | xargs pkg info
libX11-1.7.2,1
qt5-gui-5.14.2
qtchooser-66_4
qt5-core-5.15.2_5
2021-11-05 17:41:01+0000 UTC 1636134061 h440nndytpo3mqsdvcmtoeu3tppdnchwt85snd.h440nndytpo3mqsdvcmtoeu3tppdnchwt85snd 9 ~ $

Clearly even the QT 5.15.x packages reference 5.14.x packages.  That should never be allowed by package management.  Even more clearly many QT packages are not even listed as related to base QT package as one possible reason/part why this mess of incompatible mixed versions of QT packages has occurred.

If you are confidant that these mixed release of QT packages is not a xpdf issue then it would make sense to reassign this issue to those that look after the QT packages to have them address the issue.
Comment 10 Cy Schubert freebsd_committer freebsd_triage 2021-11-05 19:21:31 UTC
The problem was caused by some kind of corruption to your package database at the time. Agreed this should not happen but it did and now it needs special measures to fix it.

The qt5 5.15.2 packages should not reference qt5 5.14.2 packages or if they did at the time it was for a period of time. Since then xpdf was updated to 4.03 after qt5 5.15.2 was imported.

I've cc'd the pkg maintainer. But there is no upstream patch that can fix your problem except you run the recommended commands to resolve or recover your system from backups prior to the date qt5 was updated and run pkg upgrade against your qt5 packages.
Comment 11 John 2021-11-07 19:13:06 UTC
Additional research has determined this issue is caused by FreeBSD packaging and not a corrupt system package database.  This research demonstrates I was not the only person to have this issue and likewise others encountered this issue in exactly same time frame of August 2020.  This research also means it would be easy to duplicate the issue.

The suggested fix for xpdf:

pkg info -d xpdf | awk 'NR > 1 {print}' | xargs pkg info -o | awk '{print $2}' | xargs pkg upgrade -f

would fail based on the research and root cause of the issue.

This issue is in fact a bug in the FreeBSD packaging process and is not a bug nor some weird local one of system issue due to some suggested package data base corruption, not to mention it is easy to duplicate this issue.
Comment 12 Mark Linimon freebsd_committer freebsd_triage 2024-01-05 03:33:44 UTC
^Triage: canonicalize assignment and reassign.
Comment 13 Gleb Popov freebsd_committer freebsd_triage 2024-01-05 07:34:48 UTC
Most likely the problem arised from a partial upgrade. It should be fixable by a simple "pkg upgrade".