Bug 2017661
| Summary: | Conflict when upgrading F34 -> F35 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Joachim Backes <joachim.backes> |
| Component: | mingw-qt5-qtbase | Assignee: | Sandro Mani <manisandro> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 34 | CC: | daniel.mach, erik-fedora, jgrulich, jmracek, jreznik, jrohel, kde-sig, manisandro, mblaha, mhatina, packaging-team-maint, pkratoch, rdieter, rpm-software-management, than, vmukhame |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-11-14 04:07:31 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Joachim Backes
2021-10-27 07:07:32 UTC
Hi, file conflicts are not something dnf can solve, they usually signalize some packaging problems. Let's reassign this to qt5-qtbase component for further investigation. it looks like libQt5Bootstrap.prl was added in mingw-qt5-qtbase in f35. In f34 it's not included in mingw-qt5-qtbase Is there point in shipping
%{_libdir}/libQt5Bootstrap.a
%{_libdir}/libQt5Bootstrap.la
%{_libdir}/libQt5Bootstrap.prl
in qt5-qtbase-static? libQt5Bootstrap.so is used by the cross host tools under /usr/%{mingw32/64}_target}/bin/qt5, no use of libQt5Bootstrap for native packages AFAIK.
If we're sure libQt5Bootstrap is only needed for mingw64-qt5-qtbase and not core qt5-qtbase, then I'm ok with omitting it from the latter to resolve this. Qt5Bootstrap is a selected minimal subset of Qt5 sufficient for just running host the toolchain tools (moc, qmake, ...). The tools of the native packages clearly just link to the full libraries instead. (In Qt6, it was actually removed, and cross-builds don't build any host tools anymore, relying on pre-existing ones from a native build instead.) I've opened this PR: https://src.fedoraproject.org/rpms/qt5-qtbase/pull-request/7 FEDORA-2021-2d4da0c977 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-2d4da0c977 FEDORA-2021-2d4da0c977 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-2d4da0c977` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-2d4da0c977 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. I'm running FC35 since about 2 weeks after having uninstalled qtbase-static. So far, so good. But after upgrade, two packages are re-installed: mingw64-qt5-qtbase-static-5.15.2-5.fc35.noarch mingw32-qt5-qtbase-static-5.15.2-5.fc35.noarch FEDORA-2021-2d4da0c977 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. |