| Summary: | Discover should retry downloading the package when some issues (curl) happens | ||
|---|---|---|---|
| Product: | [Applications] Discover | Reporter: | Rafael Linux User <rafael.linux.user> |
| Component: | discover | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | aleixpol, fabian, nate, rafael.linux.user |
| Priority: | NOR | ||
| Version First Reported In: | 5.25.4 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Rafael Linux User
2022-09-05 07:56:19 UTC
Discover uses the PackageKit library for this; it's up to either PackageKit or the underlying package management backend to be more resilient to this type of condition. Ideally the actual package servers would be more reliable too. (In reply to Nate Graham from comment #1) > Discover uses the PackageKit library for this; it's up to either PackageKit > or the underlying package management backend to be more resilient to this > type of condition. > > Ideally the actual package servers would be more reliable too. I agree partially. I understand Discover want a "clean" working mode, without a bunch of messages for user when errors happen but why not at least to show a message to user about what choices he has available? I don't know how to proceed. I asked here cause I like Discover simplicity and user friendly information about each application. But this issue is a headache for me, an average linux user, so you can imagine a beginner user we'll desperate with this kind of issues. Thank you Yast instaler (Zypp-main and sw_single_wrapp) I understand that perspective, yeah. The user doesn't care about the technical details and just wants it to work properly! The thing is, in complex software, it's important that fixes be implemented at the right layer. As for error messages, we get them from the libraries beneath us, so we can't do much more than simply pass them on. This is why the change you're requested needs to be done in PackageKit, the PackageKit Zypper plugin, or Zypper itself. Can you check with pkcon which error message you get? (In reply to Aleix Pol from comment #4) > Can you check with pkcon which error message you get? When I need to launch pkcon? Before launch Discover or when a error appears? I'll have not a quick reply to that, cause usually issue happens when I have a lot of packages to update (more than 100) but please, tell how to use and I'll try to do this week in my PCs. Thank you!! I'm sorry. How to use pkcon? It needs parameters and don't know which they are. Could you help me about it? Thank you `pkcon update` to update `pkcon install [package name] to install something new It seems pkcon doesn't work as expected. I'll explain: "pkcon update" output is: (0%) Falló la orden: Repository unknown (command failed is translation) In fact, I did "pkcon --help" and that parameter doesn't appear. Anyway, "googling" I found: 1 - pkcon refresh (worked) 2 - pkcon update (began to do something), till it output this error: Error grave: problema con el elemento libpoppler123-22.08.0-324.4.x86_64 instalado problema con el elemento libpoppler123-32bit-22.08.0-324.4.x86_64 instalado (prblema con el elemento = trouble with element installed) Sounds like there's a problem with the repo configuration on your machine. (In reply to Nate Graham from comment #9) > Sounds like there's a problem with the repo configuration on your machine. I forgot to comment: Just after I did that commands, I did "sudo zypper dup", and works like always and, as usually, it ask me to take actions: 2 problemas: (issues) Problema: problema con el elemento libpoppler123-22.08.0-324.4.x86_64 instalado Problema: problema con el elemento libpoppler123-32bit-22.08.0-324.4.x86_64 instalado Problema: problema con el elemento libpoppler123-22.08.0-324.4.x86_64 instalado Solución 1: instalar libpoppler123-22.08.0-1.2.x86_64 del proveedor openSUSE reemplazando libpoppler123-22.08.0-324.4.x86_64 del proveedor obs://build.opensuse.org/LibreOffice Solución 2: mantener el elemento libpoppler123-22.08.0-324.4.x86_64 obsoleto Elija las soluciones usando '1' u omitir, reintentar o cancelar [1/2/o/r/c/i/?] (c): 1 Problema: problema con el elemento libpoppler123-32bit-22.08.0-324.4.x86_64 instalado Solución 1: instalar libpoppler123-32bit-22.08.0-1.2.x86_64 del proveedor openSUSE reemplazando libpoppler123-32bit-22.08.0-324.4.x86_64 del proveedor obs://build.opensuse.org/LibreOffice Solución 2: mantener el elemento libpoppler123-32bit-22.08.0-324.4.x86_64 obsoleto Elija las soluciones usando '1' u omitir, reintentar o cancelar [1/2/o/r/c/i/?] (c): 1 Resolviendo dependencias... Calculando actualización de distribución... And that's the fact. "Zypper" or "Yast" give options to user and finally can update/upgrade/install, but discover does not, so finally user need to use "ugly" ways to get it and can't use Discover :( Oh, that's just Zypper's PackageKit integration being crap then. See https://bugzilla.opensuse.org/show_bug.cgi?id=1163737. openSUSE should really just switch to DNF which already works with their packaging and which doesn't need to badger the user in these kinds of situations. It's smart enough to figure out a sane resolution itself, and hence works with PackageKit's own assumptions, and hence, works with Discover. Zypper just doesn't. (In reply to Nate Graham from comment #11) > Oh, that's just Zypper's PackageKit integration being crap then. See > https://bugzilla.opensuse.org/show_bug.cgi?id=1163737. PackageKit does not offer any way for interactive problem solution, so it's not the backend's fault. It's the backend's fault for needing user interaction to proceed in common packaging situations. Other packaging backends aren't so needy and manage to figure out a good resolution on their own. (In reply to Nate Graham from comment #14) > It's the backend's fault for needing user interaction to proceed in common > packaging situations. Other packaging backends aren't so needy and manage to > figure out a good resolution on their own. I think that's where this misunderstanding is: This is not a common packaging situation. In this case the user enabled a third-party repository and one of the packages inside conflicts with an official one. It's very intentional that zypper asks the user in this case on how to proceed. At least back when I was using OpenSUSE Tumbleweed, it was very common to have the 3rd-party PacMan repo enabled, as that was the only way to get medic codecs for tons of patented video and audio file formats. And having that repo led to this situation all the time for me. I'm now using Fedora with the RPMFusion repo installed for the same purpose, and it never needs user interaction to resolve potentially ambiguous packaging situations. It manages to resolve them itself without asking me. (In reply to Nate Graham from comment #16) > At least back when I was using OpenSUSE Tumbleweed, it was very common to > have the 3rd-party PacMan repo enabled, as that was the only way to get > medic codecs for tons of patented video and audio file formats. And having > that repo led to this situation all the time for me. > > I'm now using Fedora with the RPMFusion repo installed for the same purpose, > and it never needs user interaction to resolve potentially ambiguous > packaging situations. It manages to resolve them itself without asking me. That's because dnf doesn't care about package vendors. They actually want to do it the same way as zypper, but it's not done yet: https://bugzilla.redhat.com/show_bug.cgi?id=1788371 Hmm, that looks like it was done over two years ago and has managed to avoid bugging users to make choices while updating. (In reply to Nate Graham from comment #18) > Hmm, that looks like it was done over two years ago and has managed to avoid > bugging users to make choices while updating. It was implemented, but IIRC is still not enabled by default. (In reply to Nate Graham from comment #16) > At least back when I was using OpenSUSE Tumbleweed, it was very common to > have the 3rd-party PacMan repo enabled, as that was the only way to get > medic codecs for tons of patented video and audio file formats. And having > that repo led to this situation all the time for me. > > I'm now using Fedora with the RPMFusion repo installed for the same purpose, > and it never needs user interaction to resolve potentially ambiguous > packaging situations. It manages to resolve them itself without asking me. It's true, but neccesary. NVidia, Mozilla, Chrome, LibreOffice, VisualStudioCode .... are another example of external repositories that users need to add and, some times, they can fail. I must add something that still now, in 2022, I can't understand why openSUSE do this way. If user add a repository and the sign key for it, when user click on "check update" from icon in taskbar, if user didn't accepted key for that repository, openSUSE shows "Signature verification for Repository -name of repository- failed " and then user must go to console , do a "zypper refresh" , accept sign key (typing "yes") and then user can continue from desktop. That should not happen neither. Update desktop icon should ask about accept sign key to do things easier for user. (In reply to Fabian Vogt from comment #19) > (In reply to Nate Graham from comment #18) > > Hmm, that looks like it was done over two years ago and has managed to avoid > > bugging users to make choices while updating. > > It was implemented, but IIRC is still not enabled by default. If it demands interaction like Zypper does, that's a shame, because it will be buggy in the same way. Maybe PackageKit needs to gain the ability to forward user interaction requests up to its implementing app. |