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 problem with trying to make an upstream unfiied package 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. I pinged Martin over at KDE to comment here about the viability of that proposal. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1540135 Title: Make this metapackage conflict with kaccounts-providers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/account-plugins/+bug/1540135/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
