Description of problem: Since the fedora drop of some encumbered codec, there is a need to provide an alternate version of the vaapi (and vdpau) drivers backend. One step forward was to drop the vaapi backend into a separate sub-package so it could be possible to switch between fully implemented backend and the partial version provided by Fedora. But then the mesa package was enabled by default with enforced version (first with requires, then with recommends). This have the bad side effects in that on every fedora package update (even updating the release field), the 3rd part counterpart needs to be updated along (with no changes wrt the rpmfusion counterpart). Version changes are still expected. Version-Release number of selected component (if applicable): mesa-22.x.fc37 How reproducible: always Steps to Reproduce: 1. enable rpmfusion-free 2. dnf swap mesa-va-drivers mesa-va-drivers-freeworld 3. Actual results: It breaks if the release field isn't the same Expected results: Package should tolerate a different release field and enforces the same version. Additional info: From the fedora perspective, this is implemented by allowing optional mesa-va-drivers package by dropping the versionned recommends and enforcing a conflict with lower version so that in the mesa-va-drivers case, the higher version is still expected. This will allow for the 3rd part package to drop the "same evr" virtual provide that needs to be adapted each time the mesa package is touched. This requires a fix in the 3rd part counterpart repository: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6426#c111 This is implemented with https://src.fedoraproject.org/rpms/mesa/pull-request/18
@airlied (since you already helped for the initial sub-package split).
Also worth mentioning this alternate way to provide an alternative vaapi backend, long term solution: https://github.com/intel/libva/issues/639
I took care of this in https://src.fedoraproject.org/rpms/mesa/c/67698b41bb8d6427ea1763d6d7adeae387626a04?branch=rawhide
FEDORA-2023-05917b51f5 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-05917b51f5
FEDORA-2023-05917b51f5 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
Can you please submit an update for f37 as this is currently affecting users... Thanks in advance.
Sure.
FEDORA-2023-a9179f018f has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a9179f018f
FEDORA-2023-a9179f018f has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-a9179f018f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-a9179f018f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-a9179f018f has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
Pete, dropping the version check completely was probably a mistake. Please see: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6613 This needs to be adjusted somehow. Nicolas claims checking the major version should be enough. I don't know mesa internals, so I can't really say.
Pete, this is currently negatively impacting Fedora users (who happen to use va-freeworld packages): https://bugzilla.rpmfusion.org/show_bug.cgi?id=6613#c6 Can the version check be reverted at least for the time being, until a better solution is ready? Thanks!
I re-iterate here that https://src.fedoraproject.org/rpms/mesa/pull-request/18#request_diff will solve the issue on the fedora side.
(In reply to Kamil Páral from comment #12) > Pete, this is currently negatively impacting Fedora users (who happen to use > va-freeworld packages): > https://bugzilla.rpmfusion.org/show_bug.cgi?id=6613#c6 > > Can the version check be reverted at least for the time being, until a > better solution is ready? Thanks! I looked through the discussion in the rpmfusion ticket and Kevin Kofler's suggestion there to use rich deps made sense to me. I pushed https://src.fedoraproject.org/rpms/mesa/c/5967c1d99a7d7e54cdb9c2037e675b4dea4367ff?branch=rawhide as a fix. Can you test if it helps with the issue? Thanks!
FEDORA-2023-cf02ce1580 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-cf02ce1580
FEDORA-2023-74781a53b8 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-74781a53b8
FEDORA-2023-428a37804a has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-428a37804a
FEDORA-2023-428a37804a 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 Pete Walter from comment #14) > (In reply to Kamil Páral from comment #12) > > Pete, this is currently negatively impacting Fedora users (who happen to use > > va-freeworld packages): > > https://bugzilla.rpmfusion.org/show_bug.cgi?id=6613#c6 > > > > Can the version check be reverted at least for the time being, until a > > better solution is ready? Thanks! > > I looked through the discussion in the rpmfusion ticket and Kevin Kofler's > suggestion there to use rich deps made sense to me. I pushed > https://src.fedoraproject.org/rpms/mesa/c/ > 5967c1d99a7d7e54cdb9c2037e675b4dea4367ff?branch=rawhide as a fix. Can you > test if it helps with the issue? Thanks! Why are you ignoring my comment are pick a totally random person say ! Now we are back to the previous problem where the recommends was enforced ! I'm NAKING theses updates ! please concentrate on this reported pr only https://src.fedoraproject.org/rpms/mesa/c/ > 5967c1d99a7d7e54cdb9c2037e675b4dea4367ff?branch=rawhide
FEDORA-2023-cf02ce1580 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-cf02ce1580 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-74781a53b8 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-74781a53b8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-74781a53b8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Nicolas Chauvet (kwizart) from comment #19) > Why are you ignoring my comment are pick a totally random person say ! > Now we are back to the previous problem where the recommends was enforced ! > > I'm NAKING theses updates ! > please concentrate on this reported pr only > https://src.fedoraproject.org/rpms/mesa/c/ > > 5967c1d99a7d7e54cdb9c2037e675b4dea4367ff?branch=rawhide Ok, first of all, Kevin Kofler is not a random person. Kevin is one of the most knowledgeable Fedora packagers and I trust his opinion. Second, you have made the linked rpmfusion ticket private so I can no longer quote the comments there. Third, QA asked to change this (see Kamil's comments above) so that the rpmfusion version gets removed if it doesn't match the major mesa version (because of the linked bug and breaking users computers, but again I can't quote the text there any more), which is what this change now implements. It does not enforce patch version matching so if rpmfusion keeps moderately up to date it should be all good. Fourth, I am done listening to all the yelling and abuse. Did you even test the change or are you just yelling for the sake of yelling? I am done replying to you. Kamil and Kevin, can you check please if this change looks good now? Thanks!
The tightened Recommends in the Fedora package are certainly a step in the right direction, though they are only a weak dependency and hence not a guarantee that the version requirement will be satisfied. If you want to guarantee it (without making mesa-va-drivers a hard dependency), I think this should work: Recommends: %{name}-va-drivers%{?_isa} Requires: ((%{name}-va-drivers%{?_isa} >= %{?epoch:%{epoch}:}%{major}.%{minor} with %{name}-va-drivers%{?_isa} < %{?epoch:%{epoch}:}%{major}.%{minor_next}) if %{name}-va-drivers%{?_isa}) That said, I do not understand why the RPM Fusion admins are so reluctant to try any solution on the RPM Fusion side, one responding with rude language like "I don't give a toss what you think.", the other discarding my solution as "a totally random person say" without discussing the merits. RPM Fusion also still refuses to even try my very simple suggestion (that is not even a rich dependency, so no way it can break anything in their outdated infrastructure) for the versioned Conflicts: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6426#c108 instead shipping packages with file conflicts and without Conflicts, which is not only a blatant violation of https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_implicit_conflicts but also causes file conflicts during end users' upgrades.
[things are a bit heated up and from my point of view errors were definitely made on both sides; I'll try to ignore all of that here and in further comments: I'm only interested in solving the technical problem, not the "cooperation between individuals on Fedora's and RPM Fusion's side" problem] [note: I'm the mesa-freeworld co-maintainer; I only signed up to be something like a "package update monkey when Fedora updates its mesa", as these days I'm not that familiar with details on packaging/rpm/dnf any more, like I used to be ~10 to 15 years ago; that's why I tried to stay out of this discussion and leave things to the mesa-freeworld primary maintainer] Can anybody please remind me if this question was already answered: * if we ignore the LLVM problem we recently had in F38[1], do we need a tight dependency at all? And if we need one: how tight does it really have to be? [1] e.g. mesa-freeworld caused segfaults for a while, as its drivers were still build with LLVM15, when Fedora was already shipping a rebuild mesa package (same major.minor version) build against LLVM16 I ask, because I think I more than once accidentally used /usr/lib64/dri/radeonsi_drv_video.so from say mesa-va-drivers-freeworld-23.0.2 with mesa-23.0.1 without problems; I think I even used combinations like mesa-va-drivers-freeworld-22.3.1 and mesa-22.2.6 without problems, too. And from the following command it looks like at least radeonsi_drv_video.so does not depend on mesa (but I might be missing something obvious here! if I do, please tell me!): $ for file in $(ldd /usr/lib64/dri/radeonsi_drv_video.so | awk '{ print $3; }'); do rpm -qf ${file}; done | sort | uniq elfutils-libelf-0.189-1.fc38.x86_64 expat-2.5.0-2.fc38.x86_64 glibc-2.37-1.fc38.x86_64 libdrm-2.4.114-2.fc38.x86_64 libedit-3.1-45.20221030cvs.fc38.x86_64 libffi-3.4.4-2.fc38.x86_64 libgcc-13.0.1-0.12.fc38.x86_64 libstdc++-13.0.1-0.12.fc38.x86_64 libX11-xcb-1.8.4-1.fc38.x86_64 libXau-1.0.11-2.fc38.x86_64 libxcb-1.13.1-11.fc38.x86_64 libxshmfence-1.3-12.fc38.x86_64 libzstd-1.5.5-1.fc38.x86_64 llvm-libs-16.0.0-2.fc38.x86_64 ncurses-libs-6.4-3.20230114.fc38.x86_64 zlib-1.2.13-3.fc38.x86_64 Regarding the the LLVM problem we recently had with F38 another question: * Those sorts of problems are only supposed to happen in devel/beta branches, yes? Because those afaics can only be solved through a really tight dependency, which is impossible to get right currently in the Fedora world: even if Fedora and RPM Fusion push updated packages at the exact same moment (which RPM Fusion from what I've heard is not capable of due to resource limitations), dnf on some clients might pick the latest Fedora updates repo, but use an older RPM Fusion updates repo (or the other way around) and thus cause conflicts for users. /me wonders if we need a virtual provides to handle the LLVM dep properly Regarding https://src.fedoraproject.org/rpms/mesa/c/5967c1d99a7d7e54cdb9c2037e675b4dea4367ff?branch=rawhide from Peter another comment: * the comment in there says "Do not require the exact full version but rather the matching major.minor of the mesa release in order to allow for alternative providers from other repos to slightly lag behind." That comment *sounds to me* like the solution is insufficient, as mesa-freeworld sometimes will be ahead, too (for example when RPM Fusion ships a new mesa-freeworld package as regular updates, when some clients still see Fedora's mesa package in updates-testing). Or will that work as well?
(In reply to Thorsten Leemhuis from comment #24) > do we need a tight dependency at all? And if we need one: how tight does > it really have to be? We probably need a Mesa developer to answer this reliably. But I can say with certainty that major version differences can crash the system. In https://bugzilla.rpmfusion.org/show_bug.cgi?id=6613 which is now inaccessible (I tried to convince Nicolas that blocking tickets in this manner is very harmful to leading a discussion and working on a solution, but I didn't manage to convince him) I wrote: ~~~~ 1) mesa 22.3.7 + va-drivers-freeworld 22.3.7 -> video acceleration works 2) mesa 22.3.7 + va-drivers-freeworld 23.0.0 -> video acceleration doesn't work 3) mesa 23.0.0 + va-drivers-freeworld 22.3.7 -> gpu hang, loss of user session Tested with VLC, a H264 video and Radeon 580 on Fedora 37. ~~~~ Note that this was Fedora 37 (not related to the LLVM bump). Fedora performs major release bumps for Mesa even in stable releases, so it's certain that for some period of time people will get mesa of a higher major version than Mesa-freeworld. In the gpu hang case, this was the log: ~~~ Mar 23 15:04:07 titan vlc.desktop[2897]: libva info: VA-API version 1.16.0 Mar 23 15:04:07 titan vlc.desktop[2897]: libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so Mar 23 15:04:07 titan vlc.desktop[2897]: libva info: Found init function __vaDriverInit_1_16 Mar 23 15:04:07 titan vlc.desktop[2897]: libva info: va_openDriver() returns 0 Mar 23 15:04:07 titan kernel: [drm:gfx_v8_0_priv_reg_irq [amdgpu]] *ERROR* Illegal register access in command stream Mar 23 15:04:07 titan kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=1381, emitted seq=1384 Mar 23 15:04:07 titan kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process vlc pid 2897 thread vlc:cs0 pid 2916 Mar 23 15:04:07 titan kernel: amdgpu 0000:01:00.0: amdgpu: GPU reset begin! ~~~ So we definitely need to match the major version. If we implement a solution that does that reliably, it's probably a good idea to match major+minor version right away, just to be sure this doesn't break sometimes, on some systems. (With my QA hat on, I believe it's better to have a reliable system with sometimes missing hw accel, then the opposite. Unless a Mesa dev can confirm that matching only major versions is sufficient). > * Those sorts of problems are only supposed to happen in devel/beta > branches, yes? Unfortunately no, as demonstrated above, this also affects stable Fedora releases, due to both minor and major Mesa bumps during the release cycle. For a third-party repository, it's impossible to synchronize perfectly with Fedora updates. There will be always cases when a user gets only one part of the whole set. My packaging skills are limited, but I think there are basically two options how to handle this *reliably* (that's an important word in the QA world:-)): A) Delay updates. If mesa-freeworld X.Y is installed, convince dnf to not update to mesa X+1 (or X.Y+1), until mesa-freeworld X+1 (or X.Y+1) is available as well. Fedora doesn't enable "dnf --best" by default, so it could be possible to do this through rpm deps. B) Lose acceleration temporarily. If mesa-freeworld X.Y is installed and mesa X+1 (or X.Y+1) update is available, make the mesa update remove or replace the mesa-freeworld package, and once a matching mesa-freeworld update is available, make it automatically install back to the system. I'm not sure if this can be achieved. Of course, if Mesa implemented some version checking when loading *_drv_video.so and avoided loading a non-matching driver, that would allow us to use simpler approaches without the worry of crashing systems for our users. I'll try to look at the proposed solutions this week and do some tests, but I'm not really a very experienced packager, so my first step will be to study rich deps :-)
thx for your reply; will reply later in more detail (In reply to Kamil Páral from comment #25) > > * Those sorts of problems are only supposed to happen in devel/beta > > branches, yes? > > Unfortunately no, as demonstrated above, [...] FWIW, I apparently wasn't clear enough in my writing: with that "Those sorts of problems […]" I meant the "that mesa suddenly is rebuild with a newer LLVM major version"
Nicolas, how hard would it be to import a package from Fedora and ship it in the RPM Fusion repos temporarily? Then we afaics could avoid most or all of the problems by shipping a new mesa major release together with a new mesa-freeworld release in RPM Fusion, as long as RPM Fusion starts shipping the new mesa version at the same moment or a few hours before Fedora does ship it.
My patch aimed to fix kparal reported problem without also enforcing mesa-va-drivers on every version updates (despite end-users have the freeworld counterpart) as the current updates is doing. My patch isn't enforcing the fedora version on major version change purposely. I don't think assuming defunct 3part repos is going to bring any sane relationship, ever. Please drop that idea. It cause real harm and no value. As soon as this updates is still on-going , I'm reluctant to further comment on this as this here my proposal: - Revert 5967c1d99a7d7e54cdb9c2037e675b4dea4367ff and issue 23.0.2 to fedora end-users. This is a prerequisite to any sane community discussion that has to be held on this bug and nowhere else. (so the intend to close the rfbz I'm not going to discuss this again). - One proposal is made (if ever an alternative version) to pagure. - People add Pro/Con on the related pagure MR based on tests, expectation, question, whatever. (please do not assume other pov, just explain you technical reasoning). - If a consensus is rich that solves fedora/rpmfusion problems, it is adopted. Not before.
(In reply to Thorsten Leemhuis from comment #26) > FWIW, I apparently wasn't clear enough in my writing: with that "Those sorts > of problems […]" I meant the "that mesa suddenly is rebuild with a newer > LLVM major version" Ah, sorry, in that case - yes, llvm and similar rebuild issues should only happen in devel branches, as far as I know. (In reply to Nicolas Chauvet (kwizart) from comment #28) > I don't think assuming defunct 3part repos is going to bring any sane relationship I don't understand what you're trying to say.
We have had LLVM bumps in stable releases in the past, and Mesa was actually the reason (so even if we just introduce a newer LLVM for Mesa rather than systemwide, it would still be an issue), because a newer LLVM was required for new hardware support in Mesa.
Let me try to summarize things. We afaics have three related problems: (1) mesa and mesa-freeworld need to be build with the same LLVM; that is mostly a problem for devel branches, but might happen in stable releases, too (2) mesa and mesa-freeworld apparently need to have the same major.minor version, otherwise something might not work or even crash for users (3) even if Fedora and RPM Fusion start shipping a new major.minor version of mesa and mesa-freeworld in unison, dnf on clients might see one before the other -- but the update then must not proceed to avoid (2) Is that correct?
Yes, it is.
(In reply to Thorsten Leemhuis from comment #31) > Let me try to summarize things. We afaics have three related problems: > > (1) mesa and mesa-freeworld need to be build with the same LLVM; that is > mostly a problem for devel branches, but might happen in stable releases, too > > (2) mesa and mesa-freeworld apparently need to have the same major.minor > version, otherwise something might not work or even crash for users > > (3) even if Fedora and RPM Fusion start shipping a new major.minor version > of mesa and mesa-freeworld in unison, dnf on clients might see one before > the other -- but the update then must not proceed to avoid (2) > > Is that correct? Let's assume for now that it is: (1) might something we want to ignore; but if not, it afaics can only be solved if we (a) create a tight NEVR dependency between mesa and mesa-freeworld to keep them in lockstep or (b) create a virtual provides (say mesa-llvm-used) with we then ensure remain in lockstep through a dependency, which could avoid unnecessary rebuilds of mesa-freeworld (2) and (3) might be solvable with current dnf though a dependency on the major.minor version that will lead to conflicts that make dnf ignore any new mesa or mesa-freeworld package until both become available. There are various options on the table, but somebody has to test them to ensure dnf doesn't do something unexpected, like deinstalling mesa-freeworld.
The last comment is missing a "is that correct?" at the end
(In reply to Thorsten Leemhuis from comment #31) > Let me try to summarize things. We afaics have three related problems: Can you please read the topic ? None of the problem are packaging issue that are even related to the said topic. This bug is about expunging any versioned recommends that bugs freeworld users (1) and moving to strict EVR to avoid kparal reported issue (2) that in some condition fedora mesa-dri-driver and va-drivers (not the freeworld counterpart) can have a miss-match in stric EVR. None of you bothered to read the reported issue ! (1): See https://bodhi.fedoraproject.org/updates/FEDORA-2023-74781a53b8#comment-2987415 This is caused by the versioned Recommends: %{name} that we reported earlier, was reverted and now is reintroduced in mesa-23.0.2-1 (2): https://bugzilla.redhat.com/show_bug.cgi?id=2161338#c11
Peter, the path you chose in good faith for the latest update apparently caused issues for users: https://bodhi.fedoraproject.org/updates/FEDORA-2023-74781a53b8#comment-2987415 That is something none of us wants, as it's bad for Fedora reputation. Hence let me ask: Would you willing to do another rebuild where you revert your changes and give kwizart's approach a try? I can't promise that it works better, as that would require extensive and time-consuming tests. But he among us has the most experience with this sort of things, so putting some trust in him seems appropriate; and that solution afaics is unlikely to cause even bigger problems then the ones users face currently.
(In reply to Thorsten Leemhuis from comment #36) > Peter, the path you chose in good faith for the latest update apparently > caused issues for users: > https://bodhi.fedoraproject.org/updates/FEDORA-2023-74781a53b8#comment- > 2987415 Isn't this just the missing Conflicts tag that should be present? Kevin talked about it in comment 23 , last paragraph. It's also the same error as reported in https://bugzilla.rpmfusion.org/show_bug.cgi?id=6612 (way before the current update).
(In reply to Kamil Páral from comment #37) > Isn't this just the missing Conflicts tag that should be present? It might, not sure. But that made me look at the spec file again, which is when I noticed that Luya dropped the "Provides: %{srcname}-va-drivers%{?_isa}" in https://pkgs.rpmfusion.org/cgit/free/mesa-freeworld.git/commit/mesa-freeworld.spec?h=f38&id=035d8ff846474bea6415330ef4b9eb848002da02 And it's still missing in the latest packages: https://pkgs.rpmfusion.org/cgit/free/mesa-freeworld.git/tree/mesa-freeworld.spec I have no idea why, but I guess that explains why dnf is trying to install mesa-va-drivers, as it wants to satisfy the "Recommends: mesa-va-drivers", even when mesa-va-drivers-freeworld is already installed. Or am I missing something/have draw the wrong conclusion?
I believe you're right. And I think this is actually a good thing, because it will simplify adding Conflicts without the '.rpmfusion' suffix that Kevin suggested. See, mesa-va-drivers are installed out of the box on Fedora Workstation, so it doesn't make sense for rpmfusion to try to install mesa-va-drivers-freeworld automatically. It has to be deliberate action by the user (dnf swap). But if it's a manual action, the Provides don't need to be there. And adding "Conflicts: mesa-va-drivers" will make sure that DNF will not try to install them on update. So it seems to me that the issue reported in comment 36 can be resolved by adding Conflicts to the rpmfusion package. And then we can focus on keeping the Fedora and rpmfusion packages in a versioning lockstep. Am I missing something?
I see 2 issues in the RPM Fusion packaging, which together are causing the user's error: * the lack of a Conflicts, which, as I already pointed out several times, is a blatant violation of https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_implicit_conflicts * the lack of the Provides, which means that DNF will want to use the Fedora package to satisfy the weak dependency even if the RPM Fusion package is already installed. Neither is the fault of the changes made for this bug. For the Conflicts, I guess a solution would be to add a Conflicts: mesa-va-drivers-freeworld to the Fedora mesa-va-drivers, but Fedora packages should normally NOT have references to non-Fedora packages. (For Conflicts, it would at least not be a technical problem though, but mentioning the -freeworld package might be a legal problem.) I do not understand why my three-liner is NOT used by RPM Fusion. The missing Provides is something that must be addressed on the RPM Fusion end. (Theoretically, Fedora could use an or'd Recommends, but that would definitely fall afoul of the aforementioned guideline to not have dependencies on outside repositories. Conflicts might possibly be acceptable, boolean Recommends most likely not.)
I'm now in the process of testing mesa-freeworld packages with the Conflicts added, and will see if it resolves the linked problems. I'll let you know. Kevin, what is the use for the Provides you mention? Conflicts should be stronger than Recommends, so the weak dependency should have no affect (if mesa-freeworld is installed). Again, I'll test it and let you know.
> Conflicts should be stronger than Recommends, so the weak dependency should have no affect (if mesa-freeworld is installed). Even with --allowerasing or similar?
That's a good point, I'll test it as well (I think I found yet another dep issue I need to untangle first, sigh). I think we can move this Conflicts+Provides discussion to https://bugzilla.rpmfusion.org/show_bug.cgi?id=6612 and keep this issue related to just the versioning lockstep goal, in order to simplify the discussion? (But I think the Conflicts+Provides problem will be a prerequisite to solve, in order to be able to do any reasonable testing for the lockstep changes).
(In reply to Kamil Páral from comment #43) ... > But I think the Conflicts+Provides problem will be a prerequisite to solve, This is what was did originally and lead use to problem. While I agree that the conflicts should be kept, the provides cannot. The only clean design I re-interate: (that was even agreed by kparal even if he has forgot it in https://bugzilla.redhat.com/show_bug.cgi?id=2161338#c11) Fedora: from dri-drivers: - Requires: So that a strit EVR is done, this natually avoid the version missmatch as reported by kparal with the fedora va-driver sub-package, so no brainer here. - Recommends: mesa-va-drivers While keeping it un-versionned, it ensure the end-users choice will not be suddenly re-evaluated on any (minor major whatever) update. RPM Fusion side: from va-drivers: - Conflicts with fedora counterpart - Requires: mesa-filesystem%{_isa} = %{version} As we can accept a small delay between packages availability in repositories. This also allows not to hurry on every unrelated build needed on the fedora side. This is what will balance kparal reported issue and clean design (no need to compute version range or use complex rpm feature for simple problem).
> While I agree that the conflicts should be kept, the provides cannot. Why not? Because the Conflicts conflicts with itself? This: Provides: %{srcname}-va-drivers%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release} Conflicts: %{srcname}-va-drivers%{?_isa} or this: Provides: %{srcname}-va-drivers%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release} Conflicts: %{srcname}-va-drivers%{?_isa} >= %{?epoch:%{epoch}:}%{version}-%{release} or this: Provides: %{srcname}-va-drivers%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release} Conflicts: %{srcname}-va-drivers%{?_isa} <= %{?epoch:%{epoch}:}%{version}-%{release} will conflict with itself. This: Provides: %{srcname}-va-drivers%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release} Conflicts: %{srcname}-va-drivers%{?_isa} < %{?epoch:%{epoch}:}%{version}-%{release} Conflicts: %{srcname}-va-drivers%{?_isa} > %{?epoch:%{epoch}:}%{version}-%{release} will not, but it leaves a loophole for the Fedora mesa-va-drivers of the same EVR to cause a conflict. This that I suggested: Provides: %{srcname}-va-drivers%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release}.rpmfusion Conflicts: %{srcname}-va-drivers%{?_isa} < %{?epoch:%{epoch}:}%{version}-%{release}.rpmfusion Conflicts: %{srcname}-va-drivers%{?_isa} > %{?epoch:%{epoch}:}%{version}-%{release}.rpmfusion neither conflicts with itself nor allows any Fedora version of mesa-va-drivers to be installed (unless Fedora starts adding ".rpmfusion" to their EVRs ;-) ).
(In reply to Kevin Kofler from comment #45) > > While I agree that the conflicts should be kept, the provides cannot. > > Why not? Because the Conflicts conflicts with itself? ... > will not, but it leaves a loophole for the Fedora mesa-va-drivers of the same EVR to cause a conflict. Why using .rpmfusion would solve anything when conflicting ! It doesn't solve any problem and create many ! just use unversioned recommends and all your eyes bleeding hacks needs collapse !
I've provided my Conflicts testing results here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6612#c6 I think that's the first step to take here.
> Why using .rpmfusion would solve anything when conflicting ! If we have these packages: Fedora mesa-va-drivers = 24.0.0-1.fc38 RPM Fusion mesa-va-drivers-freeworld = 24.0.0-1.fc38 then: 1. if mesa-va-drivers-freeworld has: Provides: %{srcname}-va-drivers%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release} Conflicts: %{srcname}-va-drivers%{?_isa} (or Conflicts: %{srcname}-va-drivers%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release} or with >= and/or <=) it will Provide mesa-va-drivers(x86-64) = 24.0.0-1.fc38 and Conflict with it, thus Conflicting with itself = ERROR. 2. if mesa-va-drivers-freeworld has: Provides: %{srcname}-va-drivers%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release} Conflicts: %{srcname}-va-drivers%{?_isa} < %{?epoch:%{epoch}:}%{version}-%{release} Conflicts: %{srcname}-va-drivers%{?_isa} > %{?epoch:%{epoch}:}%{version}-%{release} it will Provide mesa-va-drivers(x86-64) = 24.0.0-1.fc38 and Conflict with mesa-va-drivers(x86-64) ≠ 24.0.0-1.fc38. So it will NOT conflict with itself, because the version 24.0.0-1.fc38 is carefully skipped, BUT unluckily, the Fedora package has the SAME EVR, so mesa-va-drivers-freeworld will also NOT Conflict with the Fedora mesa-va-drivers, allowing the implicit file conflicts to happen = ERROR. 3. if mesa-va-drivers-freeworld has: Provides: %{srcname}-va-drivers%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release}.rpmfusion Conflicts: %{srcname}-va-drivers%{?_isa} < %{?epoch:%{epoch}:}%{version}-%{release}.rpmfusion Conflicts: %{srcname}-va-drivers%{?_isa} > %{?epoch:%{epoch}:}%{version}-%{release}.rpmfusion it will Provide mesa-va-drivers(x86-64) = 24.0.0-1.fc38.rpmfusion and Conflict with mesa-va-drivers(x86-64) ≠ 24.0.0-1.fc38.rpmfusion. So it will NOT conflict with itself, because the version 24.0.0-1.fc38.rpmfusion is carefully skipped, BUT it WILL Conflict with the Fedora mesa-va-drivers-24.0.0-1.fc38 which does NOT have the .rpmfusion tag. And the .rpmfusion part is NOT needed in the user-visible package EVR, only in the Provides and Conflicts. I hope you understand what I mean now!
(In reply to Kevin Kofler from comment #48) > > Why using .rpmfusion would solve anything when conflicting ! > > If we have these packages: I'm not going to read any on your comment if you don't bother to comment on my "clean design solution". This is not what I've suggested earlier as any sane development process, If you want to make alternatives solution, please comment on any pagure/github(for rpmfusion) PR. You guys are using tickets like a bar talks.
Your "clean design solution" from https://bugzilla.redhat.com/show_bug.cgi?id=2161338#c44 : * due to the unversioned Recommends in the Fedora package, does not solve the issue being discussed here, that incompatible versions of mesa vs. either mesa-va-drivers or mesa-va-drivers-freeworld cause crashes for end users. Some version restrictions are needed. * due to the omitted Provides in the RPM Fusion package, does not allow the RPM Fusion mesa-va-drivers-freeworld to satisfy the soft dependency in the Fedora mesa package. That is one way to avoid the Conflicts, and we are discussing whether it is actually good enough, see https://bugzilla.redhat.com/show_bug.cgi?id=2161338#c38 and followups and https://bugzilla.rpmfusion.org/show_bug.cgi?id=6612#c6 . IMHO, the cleanest solution is not always the simplest one. I frankly think my solution with the .rpmfusion Provides/Conflicts is actually cleaner than just omitting the Provides, leaving the systems with an unsatisfied weak dependency, and hoping that the Conflicts is strong enough to prevent DNF from fulfilling that weak dependency (at the expense of the -freeworld package that would then get removed due to the Conflicts) in all situations. But in the end, what I mainly care about is that the errors our end users are reporting go away, not so much about the technical details of how. I would just appreciate that when I suggest something, it actually gets looked at and discussed as opposed to being completely ignored. (Strangely, ignoring your proposed solution is exactly what you accused me of doing.) > This is not what I've suggested earlier as any sane development process, If you want to make alternatives solution, please comment on any pagure/github(for rpmfusion) PR. > > You guys are using tickets like a bar talks. IMHO, this is exactly the kind of technical discussion for which we have Bugzilla tickets. Pull requests are not a good place to do this kind of discussion for the simple practical reason that different suggested approaches will then unavoidably lead to different pull requests and a scattered discussion. It is better to discuss the ideas first and do a pull request later, once we agree on the approach that should be used.
> * due to the unversioned Recommends in the Fedora package, does not solve the issue being discussed here, that incompatible versions of mesa vs. either mesa-va-drivers or mesa-va-drivers-freeworld cause crashes for end users. Some version restrictions are needed. This particular item wasn't intended to fix this issue! I'm not reading others comment. Please re-do your analysis without lame understanding and do some minimal effort !
> This particular item wasn't intended to fix this issue! This particular issue is what we have been discussing here since https://bugzilla.redhat.com/show_bug.cgi?id=2161338#c11 You just keep demanding an unversioned Recommends without telling us how that would address the end user issue at hand, which was in fact first reported to (and blamed by the users on) RPM Fusion: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6613 > I'm not reading others comment. And that is the main issue here. > Please re-do your analysis without lame understanding and do some minimal effort ! I have said everything I had to say about your proposal. Those 2 issues are the ones I see. If those are addressed, we have an agreeable solution. And besides, why should I spend any more time to analyze your proposal when you are not looking at mine at all?
> You just keep demanding an unversioned Recommends without telling us how that would address the end user issue at hand, Please read https://bugzilla.redhat.com/show_bug.cgi?id=2161338#c44
So, reading it all again, you want to rely on versioning on the reverse Requires, the one from mesa-va-drivers(.freeworld) requiring the main mesa package (or the mesa-filesystem one, though I think we actually want to Require mesa, not just mesa-filesystem), to enforce matching versions, is that correct? That should work if done right, but it will basically have the same advantages and drawbacks as doing the version locking in the drivers package.
This is the fedora changes I propose rebased on top of current mesa: https://src.fedoraproject.org/rpms/mesa/pull-request/20 This is the rpmfusion counterpart change: https://github.com/rpmfusion/mesa-freeworld/pull/1 > So, reading it all again, you want to rely on versioning on the reverse Requires Why reverse, just plan "uneducated" requires! We could discuss using major version if relevant, but version enforcement should be done in the rpmfusion package. At least I agree the va-drivers-freeworld should requires the (fedora) mesa-dri-drivers (that will requires the -filesystem) instead of mesa-filesystem directly. Now I re-iterate that we don't want *-freeworld users to have their packages removed
Slightly related - bug 2187726.
Packages are now desync with rpmfusion counterparts and end-users don't have 23.0.2 for no reason. I've asked in https://bugzilla.redhat.com/show_bug.cgi?id=2161338#c28 as a premise to any "sane discussion" now I'm enforcing this revert to clear end-users issue.
FEDORA-2023-404fd72f76 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-404fd72f76
FEDORA-2023-404fd72f76 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-a4c0b02c06 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-4962498b11 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-4962498b11` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-4962498b11 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I've provided my test results feedback to https://src.fedoraproject.org/rpms/mesa/pull-request/20 . It looks OK to me. My only remaining concern is bug 2187726.
I think this ticket can be closed, right? Mesa is now back to unversioned recommends, the PR is now closed as it wasn't needed, and rpmfusion will make the necessary changes on their side.
FEDORA-2023-4962498b11 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.