This morning I just boot up in OMV Lx3 to update Plasma, according to what was said in https://discourse.openmandriva.org/t/updated-plasma-and-kde-framework-packages-for-om-lx-3/200/8.
But I had a surprise. Discover (v. 5.5.1) lasted about 15 minutes to finally say “The software on this computer is up to date”. But urpmi told me in less than a minute that there were 701 packages to update.
I don’t publish this in Bugzilla yet because discover is one of the packages being updated (to 5.5.3). However, there’s no bugs reports in https://issues.openmandriva.org regarding the discover package. Does the problem in discover was previously known?
After the update I’ll see if discover and urpmi both say the same.
I found, checking System Monitor, that muon and discover are the same. So bug 1381 refers to discover doing nothing and lasting years.
Yes. I just found that !
I “CONFIRMED” the bug 1381, that was marked as “NEEDINFO”.
The bug was originally reported by @luca on October 10th 2015, three months ago.
Anyway, discover (and muon) are KDE packages. I really prefer that package maintenance be managed for a more desktop-environment independent package.
Yes it is well known problem that packagekit (muon/discover is a frontend) does not work really good with urpmi.
I’ve tried to debug this many times, and i just gave up
Is it too hard to “extract” or “adapt” part of the code (the part where talk about updates) of MCC? Or to create a front-end for “urpmi --auto-update”?
mdk-applet already do this. Why change it?
I still prefer a DE-independent way to apply updates.
PS: I don’t use just “–auto-update” but I also add “–download-all” and “–noclean”, to avoid problems when a big number of packages needs to be updated. Those options are not present in the MCC front-end, so I normally update from the CLI everytime a mdkapplet alert appears on my notification area (OMV 2014).
Feel free to propose some solution, patches, proof of concepts etc.