On 08/18/2014 10:36 PM, Rodney Dawes wrote: > We could, but I think we should try to work in the opposite direction. > Moving them into the base system means more strict requirements on what > changes they get and when they get updated, and requires a system image > update to get new ones, unless they remain in click packages, which > still has the same problem of them being in click packages and click > packages not having dependencies. If they were moved to the .debs > instead, we'd also need new frameworks so that apps depending on the > framework plug-in could declare that; otherwise we can have broken apps.
Good point. > If multiple click packages provide the same account plug-in, does > online-accounts show it multiple times, or does it get limited to the > one account type being shown in the list? Avoiding duplicates will at > least be good in the meantime, while apps do have to provide their own > copies. When you click on "Add account", you'll see all the available providers; that is, if two different click packages ship a similar account plugin, you'll see that twice. I don't think we can merge them into a single one, and in fact if you create an account using the plugin provided by the first app, you won't see it in the second app. Actually, I believe that if you have the account plugin in a click package, and two more click packages each one carrying a different application, these two application can make use of the account plugin. Of course, they cannot specify it as a dependency, but they should be able to use it. Ciao, Alberto -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
