ubuntu-appstore-developers team mailing list archive

[Alexander Sack <asac@xxxxxxxxxxxxx>]

On Wed, Jan 22, 2014 at 6:48 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx> wrote:
> On 01/22/2014 11:10 AM, Colin Watson wrote:
>> As I understand it, the agreement from the app-frameworks discussion at
>> UDS was that we wanted to be able to offer slightly more fine-grained
>> framework declarations, and allow apps to require multiple frameworks.
>> (This would also help with ABI breaks like Qt 5.2; no reason to require
>> QML-only apps to change just because we change an implementation detail
>> of the platform that only affects native-code apps.)  I planned for this
>> when laying out the Click file formats, but it didn't make the
>> implementation cut for 13.10.
>>
>> The code currently in lp:click, which will become version 0.4.14,
>> extends the "framework" manifest field a bit to support this.  With
>> this, assuming appropriate declaration files in
>> /usr/share/click/frameworks/, apps will be able to do something like
>> this:
>>
>>   "frameworks": "ubuntu-14.04-qml, ubuntu-14.04-html5"
>>
>> click does not care what the names are; these are just examples.  The
>> idea here is that if we do need to do ABI breaks in the future, at least
>> this limits the set of affected apps, and presumably we can keep the
>> most widely-used ones more stable.  I would suggest that we don't go
>> overboard on how fine-grained we make this, so that app authors don't
>> need to make overly complex decisions.
>>
>> If you have any (non-bikeshed) concerns about this, please let me know
>> before I get the landing ask for click 0.4.14 approved. :-)
>>
>
> This affects click-apparmor and while we did talk about this a bit at UDS, I
> want to restate it here. I realize click doesn't care about this, but will we
> expect things like this:
>
> "frameworks": "ubuntu-sdk-13.10, ubuntu-14.04-qml"
>
> If so, that complicates things greatly because there is one APP_ID defined per
> app in the click package and therefore only one apparmor profile per app.

I also have concerns about the case above and that going for the more
fine grained approach ultimately complicates things for not much
pratical gain...

We kind of argue that this makes it "less" painful to break apps while
it seems that everyone agrees that we never must break apps by
breaking ABIs/APIs within a major framework series.

> Because different frameworks may have different policy versions, click-apparmor
> must guess which apparmor policy version to use when generating the profile (ie,
> ubuntu-sdk-13.10 uses ubuntu/1.0 and ubuntu-14.04-qml might use ubuntu/1.1). I
> strongly recommend we not support this, but instead:
>
>  * when adding frameworks, make sure we define/use a 'base' framework. Ie, for
>    "ubuntu-14.04-qml, ubuntu-14.04-html5", the base framework is "ubuntu-14.04".
>    We should not use something like "ubuntu-14.04-qml, ubuntu-html5-14.04".
>  * when adding a framework, we need to understand what a microversion means if
>    we are going to use it. Ie, in terms of apparmor policy, is there a
>    difference between ubuntu-14.04-qml and ubuntu-14.04.1-qml such that
>    "ubuntu-14.04-qml, ubuntu-14.04.1-qml" is supposed to be supported in the
>    click manifest?
>  * click-review-tools needs to be adjusted to enforce the outcomes of this
>    thread
>
> With the above, an app developer then has a choice of either uploading
> differently versioned apps with different framework bases to the the store or
> declaring the earliest (supported) framework desired for the app.
>
> As an aside, I'd like to see the outcomes of this codified somewhere so that the
> SDK, foundations/phonedations, security, community and app store teams are all
> on the same page and to ensure adding a new framework works correctly.
>
> --
> Jamie Strandboge                 http://www.ubuntu.com/
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>