Comment 17 for bug 1574045

Revision history for this message
In , Matthew Scheirer (xanny) wrote :

The upstream solution does not actually work (it uses libaccounts-glib envars to set alternative profile directories, but apparmor will deny kaccounts access to those files, and would require permissions modifications in the Debian packages) and it breaks accounts-sso intended use (because by design, you should be placing accounts in /usr/share/accounts from multiple provider packages, which in theory could be third party).

The best case scenario would be that common providers like google.provider or twitter.provider would be unified into a shared project between the two groups, since the actual provider files are extremely similar to one another and could be unified (if you want the respective files I can upload them here as well, this is just a pretty quick reference): http://i.imgur.com/z3U67z4.png

The problem on that front is that accounts-sso is seeing very little development and is effectively in maintenance mode.

Having these packages conflict actually does not break either KDE's Telepathy or Ubuntu's Empathy - the KDE client will still load Ubuntu providers, and vice versa. The problem is they provide the same files, and thus should conflict regardless.

You could be more selective and just make account-plugin-google and account-plugin-twitter conflict for now, because then regardless of which packages you have installed google and twitter signon functionality would work. The KDE package however is not just those provider files - it also includes GUI dialogs for owncloud and generic services enablement. But then the problem becomes as KTP adds more services to its online accounts you get additional conflicts.

Fundamentally though KDE should not be patching their system settings dialogs because of a package conflict in a single distro that also breaks the Telepathy standards and introduces what would be one of very few instances of the KDE desktop imposing system wide environment variables. Either accounts-sso unifies common provider files in a shared project, or you just make packages providing the same providers conflict with one another.