[Differential] [Updated] D4667: [applet] Let specify a version for applets private plugins

[David Faure]

dfaure added a comment.


  I was always told "plugins should not get versioned at the .so level". Not sure why exactly. The more usual solution was version numbers in .desktop files, to query for things with the right version. I guess this can be transposed to json since Qt reads the json data without really loading the .so file.
  
  David Ed: you're right, but think of the case where you open a new plugin (in a long running process) which itself links to a freshly upgraded shared lib - I'm not sure what happens but it's one of these two cases:
  
  1. it loads the new shared lib next to the old shared lib -> duplicate symbols, crash.
  2. the old shared lib keeps being unused because "already loaded", and the new plugin fails to find its symbols.
  
  Overall there is no way to actually load a new plugin in an old plasma, if the underlying APIs are incompatible. So the only thing you can do is forbid loading incompatible plugins by using a version check (see above), or not support the use case at all (i.e. tell users to restart plasma after upgrading).
  
  We've had the same with kdeinit5 for ever. You upgrade KF5 (or kdelibs before) and apps, then try to run an app that needs a new symbol in kio, the long-running kdeinit5 doesn't have it, boom, undefined symbol. The only solution has always been: restarting kdeinit5 after upgrading kdelibs/KF5.

REPOSITORY
  R119 Plasma Desktop

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: anthonyfieroni, #plasma, sitter, davidedmundson, dfaure
Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20170219/323dd1e3/attachment-0001.html>