Created attachment 960216 [details] Apper error Description of problem: Using KDE Plasma 5 from Dvratil's repo, I was trying to install http://linuxdownload.adobe.com/adobe-release/adobe-release-x86_64-1.0-1.noarch.rpm but Apper returned me error "Your engine does not support installation of file" In #fedora-kde I have been told to fill a bugreport against PackageKit Version-Release number of selected component (if applicable): PackageKit-1.0.3-2.fc21.x86_64
According to the Apper code, the only way this can happen is if the backend claims not to support PK_ROLE_ENUM_INSTALL_FILES. I have no idea why that happens because pk_backend_install_files is implemented in pk-backend-hif.c.
The error "Current backend does not support installing files." comes from PkTransaction::installFiles in libapper/PkTransaction.cpp. The check there is: if (Daemon::global()->roles() & Transaction::RoleInstallFiles) { (and in the else case, the error is triggered). That is PackageKit-Qt syntactic sugar (don't you love C++ operator overloading?) for: if (pk_backend_get_roles(backend) & (1ull << PK_ROLE_ENUM_INSTALL_FILES))) { (see the Bitfield class in PackageKit-Qt for where the 1ull << comes from).
I was able to reproduce this in a VM, but when I wanted to debug it (by single-stepping it in GDB), the bug disappeared. So this seems to be a heisenbug. :-(
And we are actually not seeing "Current backend does not support installing files." from PkTransaction::installFiles in libapper/PkTransaction.cpp, but "Your current backend does not support installing files" from PkInstallPackageFiles::PkInstallPackageFile in PkSession/PkInstallPackageFiles.cpp. (Apper uses its session service to install files.) But the check there is the same "if (Daemon::global()->roles() & Transaction::RoleInstallFiles)".
This seems to be a race condition in PackageKit-Qt, or in Apper's use of it, depending on your point of view. In PackageKit-Qt: * Daemon::roles() just returns the roles property stored in DaemonPrivate, but * DaemonPrivate::Private() initializes itself asynchronously! Nowhere does it wait for the result, and neither does Apper.
Created attachment 960289 [details] proposed (completely untested) patch
Daniel, does the attached patch (not yet tested) look like a reasonable approach at fixing this to you? It changes the property getters such as Daemon::roles() to wait (by processing events until the signal arrives) until the properties have been initialized. If they have already been initialized, it should not change anything, but if they haven't, it will wait until initialization instead of silently returning a bogus default value.
Ping? I'd really like some feedback from Daniel Nicoletti about that patch. Failing that, I'll just apply it in the Fedora package.
Can't you patch Apper which is the one that is not doing the right thing?
Is it really? Apper just wants to read the value of a property, I think it's very crappy API for PackageKit-Qt to silently return an uninitialized value to Apper, blocking in the library is the right way to handle this IMHO. If you really want Apper to do the blocking, we still need to add a propertiesInitialized() or something method to PackageKit-Qt for Apper to block on.
PackageKit-Qt API is now ASYNC, and due to that Apper must wait for daemon is running signal. Making blocking calls has given Apper some odd behavior which I want to get rid of
Well, there would only be sync blocking in those cases where it isn't working now, and only for a few milliseconds. (It's a race condition that it happens at all.) I really don't like the idea that a property getter can return an uninitialized value, but then again I don't like async APIs to begin with. But if you think that having Apper wait for the signal is the right thing to do, well, it's your code, not mine. :-) But then I'd like to see that implemented, I'm not sure how exactly to do it that way, and the race condition needs to be fixed.
Ok, just pushed a fix that will make Apper just try to run the transaction and if it fails (due to not being implemented) the user will be notified anyway...
I can confirm that this fixes https://bugzilla.opensuse.org/show_bug.cgi?id=901067 and suggest you submit this to the upstream maintainers for integration.
apper-0.9.1-5.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/apper-0.9.1-5.fc21
pulled in upstream commit, https://projects.kde.org/projects/extragear/sysadmin/apper/repository/revisions/21d93baaf5b89a076cb128566e1ff004153f1e6a
Package apper-0.9.1-5.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing apper-0.9.1-5.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-0126/apper-0.9.1-5.fc21 then log in and leave karma (feedback).
apper-0.9.1-5.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
I have apper-0.9.1-6-fc21 and the problem is still there (is it regression?). Moreover, on second try it passes this error, allows me to press continue, shows processing of package, but instead of showing root login dialog, it displays common error that it is not possible to install package.