Bug 1163737 - Zypp PackageKit plugin exits when user interactivity would be required to solve an ambiguous packaging situation, causing updates via GUI package managers like GNOME Software and KDE Discover to fail
Summary: Zypp PackageKit plugin exits when user interactivity would be required to sol...
Status: RESOLVED WONTFIX
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: GNOME (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Major (vote)
Target Milestone: ---
Assignee: Jonathan Kang
QA Contact: E-mail List
URL: https://github.com/PackageKit/Package...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-14 19:32 UTC by Nathaniel Graham
Modified: 2023-03-10 01:07 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Nathaniel Graham 2020-02-14 19:32:54 UTC 
When you upgrade using the `zypper` CPI tool and there is an ambiguous packaging situation, a prompt is presented to the user requesting that a decision be made regarding how to proceed.

However the Zypp PackageKit plugin has no facility to do this, and also does not choose a default answer. As a result, whenever you update your system using GNOME Software, KDE Discover, plasma-pk-updates, or another PackageKit-using GUI tool and such a situation crops up, the update process just fails and cannot be completed. The update must be performed using the CLI.

This is not very user friendly. If I installed openSUSE on my mother's computer, I would get a panicked phone call every time this happened and have to perform the update manually.

Other PackageKit plugins (e.g. aptcc) manage to choose a safe default answer instead of prompting for user input in these kinds of circumstances. The Zypp plugin could and should as well.
Comment 1 Michael Andres 2020-03-09 09:15:00 UTC 
PackageKit plugin is maintained by gnome-maintainers.
Comment 2 Tobias Görgens 2021-02-19 22:45:32 UTC 
Are there any news regarding this issue?
It still exists and afaik the situation hasn't changed in the last year.
Comment 3 Jonathan Kang 2023-01-31 09:21:01 UTC 
This probably won't be fixed. For more information, check out this upstream issue.

https://github.com/PackageKit/PackageKit/issues/604

Leave a comment there if you insist changes should be made at PackageKit side.
Comment 4 Nathaniel Graham 2023-02-02 21:26:24 UTC 
It's unfortunate that the provider and user of the API have such different expectations.

For what it's worth, I mildly lean toward Richard Hughes' position from a UX perspective; users of a GUI updater app will, 9 times out of 10, not know what do to do resolve packaging conflicts requiring interactivity anyway. I think it would indeed be best to either do the most obviously correct thing, or at least the most non-dangerous thing. The point that requiring inactivity breaks unattended updates is also a valid one.

Relatedly: in my experience on Tumbleweed, cases where interactivity was required during an update were caused by instances of broken packaging, most commonly de-sync between the Packman repo and the main repo. I've since moved to Fedora KDE with the RPMFusion repo (which serves a similar function to the Packman repo in openSUSE land), and I have not once experienced the kind of repo de-sync problems that required manual interactivity there, or in fact any kind of broken packaging issues at all, ever. So it also seems possible to minimize the condition causing this requirement in the first place, at least. And from a user perspective, that's the best solution.
Comment 5 Jonathan Kang 2023-03-02 03:27:04 UTC 
(In reply to Nathaniel Graham from comment #4)
> It's unfortunate that the provider and user of the API have such different
> expectations.
> 
> For what it's worth, I mildly lean toward Richard Hughes' position from a UX
> perspective; users of a GUI updater app will, 9 times out of 10, not know
> what do to do resolve packaging conflicts requiring interactivity anyway. I
> think it would indeed be best to either do the most obviously correct thing,
> or at least the most non-dangerous thing. The point that requiring
> inactivity breaks unattended updates is also a valid one.
> 
> Relatedly: in my experience on Tumbleweed, cases where interactivity was
> required during an update were caused by instances of broken packaging, most
> commonly de-sync between the Packman repo and the main repo. I've since
> moved to Fedora KDE with the RPMFusion repo (which serves a similar function
> to the Packman repo in openSUSE land), and I have not once experienced the
> kind of repo de-sync problems that required manual interactivity there, or
> in fact any kind of broken packaging issues at all, ever. So it also seems
> possible to minimize the condition causing this requirement in the first
> place, at least. And from a user perspective, that's the best solution.

I do agree. There is definitely room to improve at openSUSE on how to properly distribute software/packages in various repositories, so that such issues can be minimized.
Comment 6 Jonathan Kang 2023-03-10 01:07:11 UTC 
Based on the fact that PackageKit won't support interactively resolving package conflicts, and there is nothing that can be done at the zypp backend side, I'm closing this as RESOLVED WONTFIX.