Bugzilla – Bug 1155624
[Build 20191030] PackageKit: cancels entire transaction if one package already installed
Last modified: 2020-03-13 02:19:35 UTC
## Observation openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-extra_tests_on_kde@64bit fails in [libqt5_qtbase](https://openqa.opensuse.org/tests/1072910/modules/libqt5_qtbase/steps/21) the pkcon call asks to install multiple packages, of which one is already installed. Newly, this is RETVAL 7 for PK, but it cancells the entire transaction. The behavior of zypper is better in this regards: accept the queue to be done, ignore the one already installed ## Test suite description ## Reproducible Fails since (at least) Build [20191024](https://openqa.opensuse.org/tests/1065903) ## Expected result Last good: [20191023](https://openqa.opensuse.org/tests/1065144) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=DVD&machine=64bit&test=extra_tests_on_kde&version=Tumbleweed)
Since there was no single reaction to this bug by the patch author, the patch has been reverted: <revision rev="194" vrev="15"> <srcmd5>9673a330ac8e44dca5f73b75a37aa617</srcmd5> <version>1.1.12</version> <time>1573051581</time> <user>dimstar_suse</user> <comment>Revert - https://bugzilla.opensuse.org/show_bug.cgi?id=1155624</comment> <requestid/> </revision> Feel free to rework the patch and resubmit it
*** Bug 1155162 has been marked as a duplicate of this bug. ***
When zypp finds an already installed package in the packages to be installed, it emits an errorcode to PackageKit. And PackageKit shows the message saying which package is already installed. While this error code is fatal, PackageKit terminates the transaction. And there is no other way of informing PK about this. So either we tell users which package is already installed and terminate the transaction or we proceed the transaction without telling users anything.
Can't we do the same as zypper itself does and continue the transaction with the 'already installed package' removed from the list? This is much more convenient than asking the user to remove the package from the list himself
(In reply to Dominique Leuenberger from comment #4) > Can't we do the same as zypper itself does and continue the transaction with > the 'already installed package' removed from the list? That's doable without showing users which packages are not installed because of what. Sure it'll be great if we show a summary after the installation of what's going on, like what zypper does. But PK doesn't have a proper API to implement that at the moment. The closest we can achieve now is: # a is installed in the system, while b and c is not. $ pkcon install a b c Resolving bla bla The following packages have to be installed: b description of package b c description of package c Proceed with changes? [N/y] y Installing bla bla Finished Fatal error: a is already installed.
(In reply to Jonathan Kang from comment #5) > The closest we can achieve now is: > > # a is installed in the system, while b and c is not. > $ pkcon install a b c > Resolving bla bla > The following packages have to be installed: > b description of package b > c description of package c > Proceed with changes? [N/y] y > Installing bla bla > Finished > Fatal error: a is already installed. It shouldn't be a 'Fatal error' (it's rather an information) - and pkcon should not exit with error code - the rest is acceptable
(In reply to Dominique Leuenberger from comment #6) > (In reply to Jonathan Kang from comment #5) > > The closest we can achieve now is: > > > > # a is installed in the system, while b and c is not. > > $ pkcon install a b c > > Resolving bla bla > > The following packages have to be installed: > > b description of package b > > c description of package c > > Proceed with changes? [N/y] y > > Installing bla bla > > Finished > > Fatal error: a is already installed. > > It shouldn't be a 'Fatal error' (it's rather an information) - and pkcon > should not exit with error code - the rest is acceptable This is as close as we can get with how PK works now. PK doesn't have a mechanism to allow backend pass a summary. Let's just ignore those already installed packages and proceed installing others atm.
PK 1.1.13 was resubmitted to TW, sadly still with this issue unresolved : https://openqa.opensuse.org/tests/1196729#step/gnucash/14
Should be fixed with https://build.opensuse.org/request/show/784092.