Created attachment 1940226 [details] Journalctl from the affected machine. Description of problem: With the latest build https://bodhi.fedoraproject.org/updates/FEDORA-2023-6c1c40d160, Gnome Software can arrive into a situation when it does not show a package that has been installed via dnf. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Run Software and install a package. 2. Check if installed via `rpm -qa package` -> it will be installed correctly. 3. Close Software. 4. Wait for 10 minutes as the new functionality should make PackageKit stop running after 5 minutes, so this should be enough time. 5. Install a package with dnf. 6. Started Software again and search for the above installed package, it will be reported as "not installed". 7. Attempt to install it -> this will throw out an error saying it has been already installed, the GUI still reports that the package is not installed. 8. Reboot the computer. The package will be correctly shown as installed. Actual results: See the image: https://imgur.com/a/ssultUQ. Expected results: Each time a package is installed with different methods than PackageKit, it should be immediately visible in Software, too. Additional info: I am attaching the journal, but I was unable to locate any problems there. I am keeping the VM for further testing, if you want to suggest something.
I was able to reproduce the problem as reported with the updates from https://github.com/PackageKit/PackageKit/pull/600, but only once. Is this process repeatable for you with PackageKit-1.2.6-1.fc37 ? Do you ever see the same results if you attempt to repeat with PackageKit-1.2.5-2.fc37 ? Testing on my own host gives me inconsistent results. I've seen the condition you describe at least once with both versions of PackageKit, but most of the time gnome-software shows the correct application state after installing "gnucash" with dnf. (However, most of the time it will incorrectly show that package as installed after removing it with dnf.)
I am going to try those combinations tomorrow and will let you know. Thanks for working on this.
Fwiw, this isn't surprising. dnf and PackageKit maintain separate package metadata (with potentially different caching policies). There's at least several other bugs tracking this similar issue for awhile, bug #1885022 is one
Hello, Rex, I am aware of this behaviour, but I opened this bug to specifically let @gordon.messmer know about this for the 1.2.6-1 version that was announced for testing by @mcatanza and the announcement claimed that the overall behaviour of PackageKit, especially with regards to DNF should have been solved. I can easily reproduce with both suggested versions, Gordon.
The problem here is I was worried that Gordon's update could introduce new desyncs between GNOME Software vs. dnf, so I requested testing to make sure it doesn't happen. But I naively assumed that GNOME Software worked properly as a baseline. This was wrong. So as far as I can tell, Gordon's update does not make things worse... right? It seems Milan has submitted fixes to both PackageKit and libdnf to fix the preexisting desyncs. However, he didn't follow up and neither fix moved. Both need to land to fix everything properly. The required additional fixes are: https://github.com/rpm-software-management/libdnf/pull/1542 https://github.com/PackageKit/PackageKit/pull/555
> the announcement claimed that the overall behaviour of PackageKit, especially with regards to DNF should have been solved. The announcement can be read that way, for sure, but the relevant changes in the PackateKit update were intended to resolve problems that result from shutting down packagekitd on idle (which has been turned on and off in the past), not all sync issues. For the purpose of QA, I think we're only interested in issues that can be reproduced with the updated version that do not exist in PackageKit-1.2.5-2.fc37.x86_64 Thanks for testing, Lukas.
Well we're still independently interested in this bug, of course, because we shouldn't have these desyncs. But it's not something that should block the PackageKit update.
As far as I can tell, Gordon's update does not make things worse. I was thinking that when PackageKit shuts down on idle, it could refresh the info when coming up again and be up-to-date all the time. As far as usability is concerned, some people use Software to install packages, some use DNF, some use both, but I doubt that anyone uses Software and DNF at the same time. On the other hand, people do not have to restart their computers for some time, so to sync up during reboots is not enough.
> There's at least several other bugs tracking this similar issue for awhile, bug #1885022 is one I looked for other duplicate BZs and didn't find any. 1885022 isn't precisely a duplicate, and *that* one should actually be fixed by PackageKit-1.2.6-1.fc3*, even if this one isn't. Maybe it will finally actually auto-close when F38 releases. :)
So...the status here seems to be that the exit-on-idle change got reverted on F37 and F38/Rawhide, but then *un-reverted* on F38/Rawhide but not F37. So F38/Rawhide have exit-on-idle, F37 does not. Is that what we wanted? Or do we want to un-revert it on F37 too?
That was intended. I'm not aware of any problems with this change so it belongs in F38 and rawhide, but I'm also not quite brave enough to release it to F37.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 37 entered end-of-life (EOL) status on 2023-12-05. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.