| Summary: | Discover doesn't update packages if there are both i686 and x86_64 versions present | ||
|---|---|---|---|
| Product: | [Applications] Discover | Reporter: | Roger Noble <rnbzilla> |
| Component: | Updates (interactive) | Assignee: | Dan Leinir Turthra Jensen <leinir> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | aleixpol, ales.astone, antoine.gatineau, katyaberezyaka, nate, rdieter |
| Priority: | VHI | ||
| Version: | 5.24.3 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/discover/commit/4907ad07eeaa100d425cd9a4fbcc64f1e30d6adc | Version Fixed In: | 5.24 |
|
Description
Roger Noble
2021-10-29 11:43:09 UTC
This issue is still present on plasma 5.23.4 on fedora 35. This would hit any user that has installed steam as it requires 32 bit dependencies. (And probably with other software) I mention this as it implies a large number of users must be impacted. I cannot reproduce with a minimal test-case on fedora 35 using plasma-discover-5.23.4-1.fc35.x86_64 $ rpm -q libwebp libwebp-1.2.1-3.fc35.x86_64 libwebp-1.2.1-3.fc35.i686 $ sudo dnf downgrade libwebp.x86_64 libwebp.i686 ... $ rpm -q libwebp libwebp-1.2.1-1.fc35.x86_64 libwebp-1.2.1-1.fc35.i686 $ pkcon refresh force ... $ pkcon update ... The following packages have to be updated: libwebp-1.2.1-3.fc35.i686 Library and tools for the WebP graphics format libwebp-1.2.1-3.fc35.x86_64 Library and tools for the WebP graphics format Proceed with changes? [N/y] n # discover notifier prompts that updates are available at this point, run plasma-discover plasma-discover UI shows 1 update available: What's New * libwebp: 1.1.1-1.fc35 --> 1.2.1-3.fc35 click "Update All", restart (for offline updates). After reboots, all pkgs were updated, $ rpm -q libwebp libwebp-1.2.1-3.fc35.x86_64 libwebp-1.2.1-3.fc35.i686 OK, for "fun" I tried this 2 more times, and now it has failed to update these last 2 times. before and after running plasma-discover to apply all updates and restart: $ rpm -q libwebp libwebp-1.2.1-1.fc35.x86_64 libwebp-1.2.1-1.fc35.i686 I'll keep repeating and testing scenarios to find out more. Indeed, I have reproduced the exact steps that you provided, and it worked fine. After that (because i'm sure i have seen the issue recently), just after the package downgrade, i have cleaned the dnf cache and "sudo rm -rf /var/cache/dnf/*" to be sure the packages are not known by the system as a new package would. Then i performed the discover update + reboot etc.... The result was that libwebp was not updated. Not sure it is linked, seeing your last comment. FYI,FWIW,YMMV yadda yadda :) dnf and packagekit do not share the same cache, so deletng /var/cache/dnf/* is not relevant to packagekit testing. OK, so we have at least 1 UI issue (possibly only cosmetic), but 1. Update says only 1 update is available. Could be argued that >1 multilib pkg with same (base) name should be listed only once. And more importantly 2. the case where there's at least 1 multilib package doesn't get updated Comparing with some results with 'pkcon update -d', plasma-discover behavior is different. I don't know if this is a fair comparision, but one works and the other doesn't. pkcon update -d results in a file generated /var/lib/PackageKit/prepared-update containing: [update] prepared_ids=libwebp;1.2.1-3.fc35;i686;updates,libwebp;1.2.1-3.fc35;x86_64;updates and find /var/cache/PackageKit/ -name *.rpm lists the 2 downloaded packages in question When running plasma-discover to install (offline) updates, it results in /var/lib/PackageKit/prepared-update containing only one of the items that pkcon does. After 2 tests so far, once it included only i686, the second time only x86_64. The combination of these two findings makes me wonder if the UI quirk of only showing one (of 2) is also a symptom of the problem here. Still reproducible with 5.24.x versions, see also downstream fedora report, https://bugzilla.redhat.com/show_bug.cgi?id=1963770 Git commit 4907ad07eeaa100d425cd9a4fbcc64f1e30d6adc by Alessandro Astone. Committed on 01/04/2022 at 09:23. Pushed by ngraham into branch 'master'. pk: Consider multiple package ids for one upgradeable resource One package may be installed with multiple architectures, and thus the package name shall not be considered unique for the update transaction. There are a few ways to achieve that, but this is the one that requires the less refactoring of the packagekit backend. M +4 -3 libdiscover/backends/PackageKitBackend/PackageKitBackend.cpp M +1 -1 libdiscover/backends/PackageKitBackend/PackageKitBackend.h M +3 -3 libdiscover/backends/PackageKitBackend/PackageKitResource.cpp M +9 -9 libdiscover/backends/PackageKitBackend/PackageKitUpdater.cpp https://invent.kde.org/plasma/discover/commit/4907ad07eeaa100d425cd9a4fbcc64f1e30d6adc I'm glad to see this fixed, since not having it blew up my wife's computer yesterday. Eager to se it backported, if possible. Git commit 222122cb962780bde91a97852b6a32a7172285ae by Aleix Pol Gonzalez, on behalf of Alessandro Astone. Committed on 04/04/2022 at 13:38. Pushed by apol into branch 'Plasma/5.24'. pk: Consider multiple package ids for one upgradeable resource One package may be installed with multiple architectures, and thus the package name shall not be considered unique for the update transaction. There are a few ways to achieve that, but this is the one that requires the less refactoring of the packagekit backend. (cherry picked from commit 4907ad07eeaa100d425cd9a4fbcc64f1e30d6adc) M +4 -3 libdiscover/backends/PackageKitBackend/PackageKitBackend.cpp M +1 -1 libdiscover/backends/PackageKitBackend/PackageKitBackend.h M +3 -3 libdiscover/backends/PackageKitBackend/PackageKitResource.cpp M +9 -9 libdiscover/backends/PackageKitBackend/PackageKitUpdater.cpp https://invent.kde.org/plasma/discover/commit/222122cb962780bde91a97852b6a32a7172285ae Cherry-picked |