D28701: Add KPackage support to KNewStuffCore

Tue Apr 21 10:39:59 BST 2020

leinir added a comment.

  In D28701#652898 <https://phabricator.kde.org/D28701#652898>, @ngraham wrote:

  > Great. There are still a few more bugs though:
  >
  > When you install certain global themes, they ask for authentication so install an SDDM theme. However when you uninstall that theme, it doesn't request authentication to remove them SDDM theme. So `/usr/share/sddm/themes` accumulates a growing collection of unused themes:
  >
  >   ls /usr/share/sddm/themes/
  >   breeze  breeze-openSUSE  elarun  Layan  maldives  maya  McMojave  plasmaX  Sweet
  >

  Not a huge amount knewstuff can do about that, that'll need to be done by the sddm kpackage plugin (mind you, having not looked i don't imagine this would be a huge issue, more a bit of forgotten implementation work in said plugin, since it already has the logic to ask on installation i don't imagine it would be a huge amount of effort to get it to do that on uninstallation as well).

  > When I install and uninstall the Sweet global theme, its Plasma theme still shows up in the Plasma style KCM. And looking in `~/.local/share/plasma/desktoptheme/`, there are several orphaned plasma themes left over from global themes that I deleted from the GHNS dialog on the global themes KCM:
  > 
  >   ls ~/.local/share/plasma/desktoptheme/
  >   Arc-Dark  kpluginindex.json  Layan  Sweet
  > 
  > 
  > Their color schemes and icon themes are still there too.

  i can confirm this is happening, yup - however, this isn't knewstuff specifically, this is kpackage in general (you will notice this with any kpackage which has dependencies). I would suggest it is out of the scope for this specific patch to fix that problem, but it's definitely something we'll want to sort out (but also, if you have ever run apt-get purge or autoremove, that's the territory we're veering into here... that is to say, doable, but not trivial or automatically doable, as there's no guarantee that nothing else depends on that package being there).

  Now, what we /could/ do is allow the user to just go "yup, please remove all the dependencies as well" for packages which have dependencies listed, but i am thinking that that is starting to sound quite dangerous... As in, what happens when a user goes "yes, i definitely know what i'm doing" and clicks that option, only to then discover that no, those dependencies were also needed by some other thing (i imagine a fair few global themes would have similar dependencies) and now that other thing just outright breaks when attempting to apply it. Again, this should hopefully be solvable, but i'm not sure how much work that would be. Arguably in scope here if we want to ask, but it's not a regression (by which i mean kpackage -r Sweet -t Plasma/LookAndFeel would also leave those other bits behind).

REPOSITORY
  R304 KNewStuff

REVISION DETAIL
  https://phabricator.kde.org/D28701

To: leinir, #plasma, #knewstuff, #frameworks, ngraham, mart, davidedmundson, broulik, bshah
Cc: ngraham, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200421/ea5009eb/attachment-0001.html>