User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/112.0 Build Identifier: As reported in https://bugzilla.rpmfusion.org/show_bug.cgi?id=6641 , it might happen that some third-party package depending on mesa-filesystem (or mesa-dri-drivers) keeps mesa from upgrading. But it doesn't keep the whole mesa, some subpackages are happy to update separately: $ sudo dnf update mesa\* --releasever 38 Last metadata expiration check: 0:40:25 ago on Tue 18 Apr 2023 12:11:04 PM CEST. Dependencies resolved. Problem: cannot install the best update candidate for package mesa-va-drivers-freeworld-22.2.2-1.fc37.x86_64 - nothing provides mesa-filesystem(x86-64) >= 23.0.2 needed by mesa-va-drivers-freeworld-23.0.2-1.fc38.x86_64 ============================================================================== Package Arch Version Repository Size ============================================================================== Upgrading: mesa-libEGL x86_64 23.0.1-2.fc38 fedora 130 k mesa-libGL x86_64 23.0.1-2.fc38 fedora 173 k mesa-libgbm x86_64 23.0.1-2.fc38 fedora 44 k mesa-libglapi x86_64 23.0.1-2.fc38 fedora 54 k Skipping packages with broken dependencies: mesa-va-drivers-freeworld x86_64 23.0.2-1.fc38 rpmfusion-free 3.4 M In this case, the effect would be that mesa-dri-drivers would be kept at version 22.3, while the four mesa subpackages would be upgraded to version 23.0. Are you sure this is safe? Is this a supported behavior? If this is safe, please disregard this report. If those 4 subpackages shouldn't differ in version, but the intention is to make them installable separately (without mesa-dri-drivers), a solution could be to make them require mesa-filesystem of that particular version (as is the case with e.g. mesa-va-drivers). That would make them installable standalone but still match the current mesa-dri-drivers version. Reproducible: Always
The fedora mesa package can upgrade here because it still satisfy the previous mesa-va-drivers-freeworld-22.3: Requires: mesa-filesystem >= 22.3 If enforcing a "version match" (to either -filesystem or better -dri-drivers), such upgrade isn't possible anymore. -> va-driver-freeworld will enforce same epoch-version to -dri-drivers. (and tolerate release changes). -> dri-drivers will enforces strict EVR dependencies between fedora mesa subpackages. This is either none or all situation that is bugs free.
Reminder for the rpmfusion counterpart changes: https://github.com/rpmfusion/mesa-freeworld/pull/1
I experimented with the proposed patches and I found even a bigger set of subpackages which can be updated standalone: Upgrading: mesa-libEGL x86_64 23.0.3-1.pull20.fc38 tmp 130 k mesa-libGL x86_64 23.0.3-1.pull20.fc38 tmp 173 k mesa-libgbm x86_64 23.0.3-1.pull20.fc38 tmp 45 k mesa-libglapi x86_64 23.0.3-1.pull20.fc38 tmp 54 k mesa-libxatracker x86_64 23.0.3-1.pull20.fc38 tmp 2.1 M mesa-vulkan-drivers x86_64 23.0.3-1.pull20.fc38 tmp 9.0 M Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): mesa-filesystem x86_64 23.0.3-1.pull20.fc38 tmp 18 k Skipping packages with broken dependencies: mesa-dri-drivers x86_64 23.0.3-1.pull20.fc38 tmp 18 M So all these subpackages (and ideally all subpackages) should be verified whether they can really work well when they're updated but paired with an older mesa-dri-drivers (can be even one major version lower). And if not (or if you want to play it safe), they should have an exact version requirement on mesa-filesystem (or a different solution to match versions).
(In reply to Kamil Páral from comment #3) > I experimented with the proposed patches and I found even a bigger set of > subpackages which can be updated standalone: > > Upgrading: > mesa-libEGL x86_64 23.0.3-1.pull20.fc38 tmp 130 k > mesa-libGL x86_64 23.0.3-1.pull20.fc38 tmp 173 k > mesa-libgbm x86_64 23.0.3-1.pull20.fc38 tmp 45 k > mesa-libglapi x86_64 23.0.3-1.pull20.fc38 tmp 54 k > mesa-libxatracker x86_64 23.0.3-1.pull20.fc38 tmp 2.1 M > mesa-vulkan-drivers x86_64 23.0.3-1.pull20.fc38 tmp 9.0 M > Skipping packages with conflicts: > (add '--best --allowerasing' to command line to force their upgrade): > mesa-filesystem x86_64 23.0.3-1.pull20.fc38 tmp 18 k > Skipping packages with broken dependencies: > mesa-dri-drivers x86_64 23.0.3-1.pull20.fc38 tmp 18 M > > > So all these subpackages (and ideally all subpackages) should be verified > whether they can really work well when they're updated but paired with an > older mesa-dri-drivers (can be even one major version lower). mesa-vulkan-drivers and mesa-libxatracker should be independent from any other Mesa packages, but the rest of these need to be at least the same upstream version as mesa-dri-drivers (assuming no downstream patches affecting the ABIs between mesa-dri-drivers and the other packages).
Thanks a lot, Michel. I created a PR here: https://src.fedoraproject.org/rpms/mesa/pull-request/21
FEDORA-2023-890b7c9954 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-890b7c9954
FEDORA-2023-890b7c9954 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Michel Dänzer from comment #4) > mesa-vulkan-drivers and mesa-libxatracker should be independent from any > other Mesa packages, but the rest of these need to be at least the same > upstream version as mesa-dri-drivers (assuming no downstream patches > affecting the ABIs between mesa-dri-drivers and the other packages). Michel, additionally, we identified mesa-libd3d as currently having no relation to other mesa subpackages. Would you know whether this is correct (it's completely independent), or whether libd3d should be also version locked to e.g. mesa-dri-drivers or something else? Thanks!
(In reply to Kamil Páral from comment #8) > Michel, additionally, we identified mesa-libd3d as currently having no > relation to other mesa subpackages. Yeah, AFAICT it's independent. One caveat is that it links LLVM; if the same Wine process were to end up loading both d3dadapter9.so.1 and another Mesa binary linking against another version of LLVM, that might not end well. But I don't know if that can actually happen in practice.
Thanks for confirmation, Michel. Yeah, LLVM is a different issue, and it's not just related to libd3d. I leave it up to mesa maintainers to think about that :) This particular issue is therefore solved now. Thanks everyone.
As a short follow-up, updating just part of the mesa stack is indeed a problem, GNOME fails to start for people: https://www.reddit.com/r/Fedora/comments/131lvjp/system_got_totally_borked_after_upgrading_to_mesa/ This should hopefully be resolved once everyone has mesa-23.0.3-1 or later.
*** Bug 2191745 has been marked as a duplicate of this bug. ***
*** Bug 2192176 has been marked as a duplicate of this bug. ***
Unfortunately this doesn't seem fully fixed. See bug 2193135.