SUMMARY When an error downloading a package happens, Discovery report user it but give user no chance to retry, so user must restart all update. STEPS TO REPRODUCE 1.Launch Discover and wait it to show packages to update (5000+ in this case) 2. Click on "Update all" OBSERVED RESULT When some issue happens (in my case, EXPECTED RESULT SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220820 KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.19.2-1-default (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-9700K CPU @ 3.60GHz Memory: 15.5 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2060/PCIe/SSE2 ADDITIONAL INFORMATION In openSUSE, on my local network, sometimes I can get 3 o 4 times errors when downloading packages, like next one: "#sudo zypper dup Recuperando: libXext6-1.3.4-1.15.x86_64.rpm ...........................................................................[error] Error de descarga (curl) para https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/x86_64/libXext6-1.3.4-1.15.x86_64.rpm: Código de error: Curl error 92 Mensaje de error: HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)" or "Código de error: Curl error 16" and no message error. But from console, openSUSE give user a chance to retry, ignore or cancel: ¿Cancelar, reintentar o ignorar? [a/r/i/...? mostrar todas las opciones] (a): r In most cases, I can continue downloading packages after keying "r" (retry). In Discover, user have no chance to retry or even al least to know what's the issue. It should be changed to show user more info about issue and let him choose a option, not simply cancel updating. You must take into account that I'm using openSUSE Tumbleweed, so usually from month to month I need to upgrade usually more than 3.000 packages (5.000 when writing this issue), so it's a big trouble if I need to restart downloading on Discover for each package I'm having issues to download. Finally, I need to use console to get to update my system :( Thank you
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.