| Summary: | mesa-freeworld breaks F37->F38 upgrade (implicit file conflicts) | ||
|---|---|---|---|
| Product: | Fedora | Reporter: | Kamil Páral <kparal> |
| Component: | mesa-freeworld | Assignee: | Luya Tshimbalanga <luya_tfz> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | bugzilla, kevin.kofler, leigh123linux, nekohayo, nerijus, ralph, rgm |
| Priority: | P1 | ||
| Version: | f38 | ||
| Hardware: | x86_64 | ||
| OS: | GNU/Linux | ||
| namespace: | |||
|
Description
Kamil Páral
2023-03-23 14:43:06 CET
I usually use --setopt=install_weak_deps=False when upgrading with --releasever, so I've not experienced the issue. Do you have a fix to suggest ? Right Now I'm more inclined to consider this as a dnf bug. (or do you have a more verbose output to understand why the non-freeworld varriant was enforced ?) I tried to use dnf --verbose and even --debugsolver, but it doesn't contain anything useful that would help figure out why it's picking up mesa-va-drivers :-( That is because you have file conflicts, but no RPM Conflicts. RPMs with file conflicts MUST have an appropriate Conflicts tag: https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_implicit_conflicts The package MUST have versioned (to avoid conflicting with itself) Conflicts as I described here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6426#c108 These are still missing in the current version, which is why we have this bug. Just a quick update, this problem hasn't been resolved, but it might not happen to everybody. Because of this change [1], DNF no longer tries to install previously-removed weak dependencies again. So depending on your system configuration, everything can work just fine: $ sudo dnf update mesa\* --releasever 38 --enablerepo updates-testing --enablerepo rpmfusion-free-updates-testing Last metadata expiration check: 0:08:48 ago on Tue 18 Apr 2023 12:22:40 PM CEST. Dependencies resolved. ============================================================================== Package Arch Version Repository Size ============================================================================== Upgrading: llvm-libs x86_64 16.0.0-2.fc38 fedora 27 M mesa-dri-drivers x86_64 23.0.2-1.fc38 updates-testing 18 M mesa-filesystem x86_64 23.0.2-1.fc38 updates-testing 18 k mesa-libEGL x86_64 23.0.2-1.fc38 updates-testing 130 k mesa-libGL x86_64 23.0.2-1.fc38 updates-testing 173 k mesa-libgbm x86_64 23.0.2-1.fc38 updates-testing 45 k mesa-libglapi x86_64 23.0.2-1.fc38 updates-testing 54 k mesa-libxatracker x86_64 23.0.2-1.fc38 updates-testing 2.1 M mesa-va-drivers-freeworld x86_64 23.0.2-1.fc38 rpmfusion-free 3.4 M mesa-vulkan-drivers x86_64 23.0.2-1.fc38 updates-testing 9.0 M But when you have exclude_from_weak_autodetect=false, or if the mesa-va-drivers packages was removed in some particular way that DNF evaluates differently (that was my case for comment 0, no idea why), it tries to pull mesa-va-drivers again (which fails to install because of file conflicts): $ sudo dnf update mesa\* --releasever 38 --enablerepo updates-testing --enablerepo rpmfusion-free-updates-testing --setopt exclude_from_weak_autodetect=false Last metadata expiration check: 0:05:22 ago on Tue 18 Apr 2023 12:22:40 PM CEST. Dependencies resolved. ============================================================================== Package Arch Version Repository Size ============================================================================== Upgrading: llvm-libs x86_64 16.0.0-2.fc38 fedora 27 M mesa-dri-drivers x86_64 23.0.2-1.fc38 updates-testing 18 M mesa-filesystem x86_64 23.0.2-1.fc38 updates-testing 18 k mesa-libEGL x86_64 23.0.2-1.fc38 updates-testing 130 k mesa-libGL x86_64 23.0.2-1.fc38 updates-testing 173 k mesa-libgbm x86_64 23.0.2-1.fc38 updates-testing 45 k mesa-libglapi x86_64 23.0.2-1.fc38 updates-testing 54 k mesa-libxatracker x86_64 23.0.2-1.fc38 updates-testing 2.1 M mesa-va-drivers-freeworld x86_64 23.0.2-1.fc38 rpmfusion-free 3.4 M mesa-vulkan-drivers x86_64 23.0.2-1.fc38 updates-testing 9.0 M Installing weak dependencies: mesa-va-drivers x86_64 23.0.2-1.fc38 updates-testing 3.4 M I'm currently testing a spec change that could resolve this. I'll update this ticket. [1] https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect I've tested this change:
%package -n %{srcname}-va-drivers-freeworld
Summary: Mesa-based VA-API drivers
Requires: %{srcname}-filesystem%{?_isa} >= %{?epoch:%{epoch}:}%{version}
+Conflicts: %{srcname}-va-drivers%{?_isa}
...
%package -n %{srcname}-vdpau-drivers-freeworld
Summary: Mesa-based VDPAU drivers
Requires: %{srcname}-filesystem%{?_isa} >= %{?epoch:%{epoch}:}%{version}
+Conflicts: %{srcname}-vdpau-drivers%{?_isa}
and it successfully prevents mesa-va-drivers from being considered again, even with exclude_from_weak_autodetect=false. I also tested --allowerasing, --best and combination of these arguments, I haven't found any issue with it.
I believe this patch should be included and it will resolve both my reported issue and also issues like these:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-74781a53b8#comment-2987415
I think I've found another small problem in the spec file, I'll report it separately and link it here in a moment.
(In reply to Kamil Páral from comment #6) I have no problem with this patch, this is uncontroversial. > and it successfully prevents mesa-va-drivers from being considered again, I disagree with the conclusion as soon a (minor,major) versioned recommend is used. Did you really tested with major update condition ? Anyway, this is what I'm suggesting: https://github.com/rpmfusion/mesa-freeworld/pull/1 I tested going from mesa-dri-drivers-22.3.7-1.fc37.x86_64 to mesa-dri-drivers-23.0.2-1.fc38.x86_64, i.e. the current update in updates-testing which has a versioned Recommends. It works fine in my testing, the Conflict is honored correctly. Just to clarify. This breaks updates on f37 in general. Not only when upgrading from f37 to f38. dnf update on f37 is not possible anymore: Error: Transaction test error: file /usr/lib64/libheif/libheif-libde265.so conflicts between attempted installs of libheif-hevc-1.15.1-2.fc37.1.x86_64 and libheif-freeworld-1.15.1-4.fc37.x86_64 file /usr/lib64/libheif/libheif-x265.so conflicts between attempted installs of libheif-hevc-1.15.1-2.fc37.1.x86_64 and libheif-freeworld-1.15.1-4.fc37.x86_64 file /usr/lib64/dri/nouveau_drv_video.so conflicts between attempted installs of mesa-va-drivers-freeworld-23.0.2-1.fc37.x86_64 and mesa-va-drivers-23.0.2-2.fc37.x86_64 file /usr/lib64/dri/r600_drv_video.so conflicts between attempted installs of mesa-va-drivers-freeworld-23.0.2-1.fc37.x86_64 and mesa-va-drivers-23.0.2-2.fc37.x86_64 file /usr/lib64/dri/radeonsi_drv_video.so conflicts between attempted installs of mesa-va-drivers-freeworld-23.0.2-1.fc37.x86_64 and mesa-va-drivers-23.0.2-2.fc37.x86_64 file /usr/lib64/dri/virtio_gpu_drv_video.so conflicts between attempted installs of mesa-va-drivers-freeworld-23.0.2-1.fc37.x86_64 and mesa-va-drivers-23.0.2-2.fc37.x86_64 This is because mesa-freeworld-23.0.2-1.fc37.1 is still not in stable updates. I hope that rpmfusion maintainers can push it today. I think I am up against this same problem on F37: Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction test error: file /usr/lib64/libheif/libheif-libde265.so conflicts between attempted installs of libheif-hevc-1.15.1-2.fc37.1.x86_64 and libheif-freeworld-1.15.1-4.fc37.x86_64 file /usr/lib64/libheif/libheif-x265.so conflicts between attempted installs of libheif-hevc-1.15.1-2.fc37.1.x86_64 and libheif-freeworld-1.15.1-4.fc37.x86_64 I think it is gthumb that is triggering this dependency, as that is all that is left to update after an update with --skip-broken mesa-freeworld-23.0.2-1.fc38.1 is stable, this should be now fixed. Robert, that is not related to mesa, but libheif. I believe the issue is already fixed now with the latest push. |