[Question] Add ability to resolve package conflicts interactively?

[JonathanKang]

When using PackageKit to manager softwares, sometimes package conflicts can happen. While currently there is no way to resolve such conflicts interactively using PackageKit.

Is it feasible to implement this in PackageKit's framework?

Currently libzypp has the ability to present problems and solutions to users so that they can choose what to do. dnf and apt seems to only present the problem to users.

[hughsie]

so that they can choose what to do

I don't think this works with the use cases that PK tries to solve. The user isn't even in the position to understand the options. It also breaks unattended updates. Just do the most correct thing.

[Conan-Kudo]

I would also argue that this is a misfeature in zypp itself, because there's no way a user understands the consequences of their actions when presented with something like this.

[Pointedstick]

Arguably a user using the CLI tool can be presumed to have enough technical skill to potentially understand the options and their consequences, but for PackageKit's usage in GUI updater apps, yeah, the chance of the user understanding is very small. I concur with the suggestion to "Just do the most correct thing" when invoked from PackageKit.

[JonathanKang]

Thanks for the comments. It makes no sense asking not-so-experienced users to resolve these package conflicts. Closing this.

[Pointedstick]

We have another use case for this: asking the user to accept (or re-accept, I suppose) a EULA during the update process; see https://bugs.kde.org/show_bug.cgi?id=461385#c30.

This isn't a packaging conflict that the underlying plugin can try its best to choose a good answer for; it's something that may be a legal requirement and that the user will definitely know what to do for (just click "yes").

Could we consider adapting PackageKit to support this use case?

[Conan-Kudo]

EULAs are different, and PK already has the ability to do this. However, only the Zypper package manager currently supports this capability. Frontends need to implement support for the relevant APIs around EULAs.

[Pointedstick]

Ohh, so that means it's a Discover bug?

[Conan-Kudo]

Yup!

[ximion]

PackageKit already has API for EULAs: https://www.freedesktop.org/software/PackageKit/gtk-doc/PkEulaRequired.html
This needs to be properly implemented by the backend and and the frontend, so Discover needs to support it, and whatever backend you use needs to support it too.

Or, actually even better, don't use PackageKit for this - use AppStream instead, it's agnostic of the backend and just needs proper implementation in a frontend to display an agreement:
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-agreement
https://www.freedesktop.org/software/appstream/docs/api/appstream-AsAgreement.html

[Conan-Kudo]

There's no way we can rely on AppStream for this. Nobody is using it that way yet.

[Conan-Kudo]

Also, no command-line package managers support processing AppStream data, which means we still need to rely on non-AppStream based stuff for this.

[ximion]

There's no way we can rely on AppStream for this. Nobody is using it that way yet.

Very much untrue, this feature only exists because there was demand for it and because people are using it (even though the main driving force was GDPR agreements and not EULAs).
The biggest consumer of this feature is Fwupd/LVFS, because, you know, lots of proprietary code ;-)

Also, no command-line package managers support processing AppStream data, which means we still need to rely on non-AppStream based stuff for this.

Have both for a transition period, or just make your package manager display it ;-) May even be less work than implementing proper backend support in PK ;-)

[Conan-Kudo]

Unfortunately, no. Zypper removed support for AppStream data because it caused problems, and it's still too expensive for Fedora to produce AppStream repodata along every compose, which would be a requirement for being able to do this properly (which is why DNF doesn't have support for processing AppStream data).