Bug 2187726
Summary: | A partial mesa update can happen when a third-party package holds back mesa-dri-drivers | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> |
Component: | mesa | Assignee: | Adam Jackson <ajax> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 38 | CC: | ajax, bskeggs, felix, igor.raits, jglisse, j, kwizart, lyude, mail, mdaenzer, ppywlkiqletw, rhughes, rstrode, thib, tstellar |
Target Milestone: | --- | Keywords: | CommonBugs |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | https://discussion.fedoraproject.org/t/common-issues/81856 | ||
Fixed In Version: | mesa-23.0.2-3.fc39 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2023-04-25 16:19:05 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Kamil Páral
2023-04-18 14:34:38 UTC
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. |