When I run apt upgrade, some packages ask interactive questions, including fairly important ones, e.g. about overwriting user’s configs.
If I run an upgrade like this from KDE Discover, what will happen? Some default answer silently submitted / upgrade skipped / UI dialog with the question shown / etc.?
Is this behavior configurable?
Does Discover have a clear documentation on this?
Ooh, I get to paste in one of my canned answers for this:
Unfortunately this issue is a caused by a design flaw in the PackageKit library that Discover relies upon for this functionality: it provides no way to bubble up interaction requests so that Discover can show them in the GUI. See [Question] Add ability to resolve package conflicts interactively? · Issue #604 · PackageKit/PackageKit · GitHub.
Equally unfortunately, there is nothing we can do in Discover short of migrating away from that library (which would entail migrating to use another library that does not current exist, and in the process rewriting half the app) until and unless the issue is fixed upstream.
The only workarounds at this point in time are for packagers to not add such interactivity in their packages themselves, or for users to not use those packages or distros.
Thanks for your reply!
So, back to my original question of “what will happen” — I guess, the answer is “Discover will show the referenced error”. OK. But apart from the error itself, what would be the end result of the upgrade operation? E.g. if I have 300 packages to upgrade, and one of them asks an interactive question, will Discover show this error and keep this one non-upgraded, but upgrade the other 299?
P.S. I’m new here and a bit surprised that my question was marked “solved”, but not by me 
Is this how it’s done here? I wouldn’t say I’m 100% clear on this, so… why so quickly “solved”?..
It depends on how the PackageKit plugin for the distro handles it.
the DNF plugin used for Fedora, for example, auto-answers all questions in some way. The APT plusin for Debian-based distros auto-answers some questions in some way, but turns others into an error. The Zypper backend for openSUSE distros auto-answers none of them, and turns them all into an error.
How errors are handled is likewise up to the specific PackageKit plugin.
Since this is a discussion forum, “solved” means “the question has been answered,” not necessarily “the problem that the question is about has been solved.” That’s what the bug tracker is for.
The definition of “solved” as you described it might be a full equivalent of “replies != 0” and unneeded as a separate manually managed concept, then
Thanks much for your answers, although this is somewhat sad, then. I really liked the idea of using Discover to upgrade everything — packages, flatpaks, firmware… possibly even using it this same way on two different distros
But at the same time I remember grub upgrade on Debian asking about overwriting, keeping or merging my /etc/default/grub. Allowing the PackageKit plugin to decide on “the most correct thing” in cases like this feels outright dangerous.
Thus I guess no matter how much I liked Discover, it’s not the time to use it yet… at least for me 
Just another thought — I think even the strategy of “skipping the upgrades of the “talkative” packages”, if implemented consistently across all distros, could be a game changer. But then again, based on your answers, it doesn’t look like Discover could reach that level of consistency on its own.
Ultimately I suspect we’ll end up ditching the PackageKit library as it just causes too many issues. In its place we’d have a different backend for each distro’s packaging system. Because 100% of the code for it would be under our control, we’d be able to do things like ask for user interaction, display logging data to the user, or anything else that distros want that we can’t currently offer. This is already happening in a form, as Discover now has in-source-tree backends for Fedora Kinoite and SteamOS. It’s just a matter of adding them for APT, DNF, Zypper, Pacman, and so on.
This will be a massive project, though. So I wouldn’t expect it anytime soon.
Sorry for the dumb question, but is that a burden that could be flipped - like some standard framework for it exists in Discover, and part of a distribution’s job in packaging Discover is following that framework to plug in their package manager accordingly? Rather than KDE having to implement things all in Discover?
(Guess I’m thinking that might at least put the burden for adapting to package-manager-specific difficulties closer to where those difficulties are being introduced?)
You just described the status quo, in fact: Discover supports the generic PackageKit library, and it’s distro packagers’ jobs to write and maintain a thin wrapper plugin that tells PackageKit how to interact with their package management system.
The problem is that PackageKit is not expansive or flexible enough to offer all the functionality that some package management systems need.
I do see that PackageKit seems to be fairly actively developed upstream again, after a period of neglect following its original author’s disengagement from the project. So maybe all is not lost for PackageKit after all and we could see if its current developers would be up for adding the ability to bubble up questions to the user.
As you pointed out in the PackageKit link you posted above, bubbling up questions to the GUI probably won’t help, as the target user probably doesn’t understand the question anyway — It’s you, the GUI, who hid all these details before so he doesn’t know.
It seems that modern GUI appstores, e.g. ios/android/windows appstores, flathub, snapstore, browser extension stores… they don’t ask questions during installation. Questions are to be asked by softwares themselves after installation, including EULA.
Linux package managers are decades old. And they are so different to each other. Probably the best a universal GUI appstore like Discover can do, is just drop the user back into the console, should any interaction be required. If the user understands the text on screen, good. Otherwise, perhaps it’s time to google.