ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 12/16/2013 10:05 AM, Dimitri John Ledkov wrote:
> On 16 December 2013 15:27, Jamie Strandboge <jamie@xxxxxxxxxxxxx> wrote:
>> On 12/16/2013 07:54 AM, Dimitri John Ledkov wrote:

...

>> Fat packages are being implemented for shipping multiple binaries for different
>> architectures in a single click package and these will be per version (which
>> should cut your example uploads above in half). I think expanding fat packages
>> to also support multiple frameworks is a mistake-- it adds a lot of complexity
>> (not least of which is how to apply security policy) and I think the benefit is
>> negligible-- apps will almost certainly not be expected to work across different
>> frameworks which suggests using different versions and if your app happens to
>> work fully with the earlier supported framework, just pick that framework rather
>> than using two (aiui, multiple frameworks will be shipped on the device).
> 
> Sounds good. Fat (as in arches) binaries should be actually
> in-practice small amount of the click size, with graphical assets /
> non-arch specific files taking the most of the application size.
> 
> How feasible do you think it is to ship a single framework at the time
> on the phone?
>
> E.g. sure compiled apps need a recompile, but I'd hope most
> "webapp-launchers" and "simple qml apps" can be bumped to next
> framework automatically, server-side at the store, without developer
> re-upload. [*]
> 

Yeah, that is a good question and I don't have a good answer. AIUI, a prime
directive of the store is to not modify the packages the developers upload so
doing this automatically on the server would require discussion across multiple
teams. OTOH, thinking about it from the security team's perspective, there is no
guarantee that the security policy is going to continue to work-- when you
upgrade the framework you must get the new security policy version. If for
example a policy group is removed in the later policy that an old app uses, the
app would fail to launch (because the policy would fail to load at install so
upstart-app-launch/aa-exec-click would fail to change_profile). It is also
possible that a policy group can move from 'common' to 'reserved' between
framework versions, which would then give any of these automatically updated
apps that used this policy group a permission that they shouldn't have when
using this version of the framework. Of course, the auto-upgrade tools could
check for these sorts of things, but we'd need to consider all of this carefully
(and there are certainly more than just the two security ones I mentioned).

> [*] e.g. subject to automated ABI/API compatibility checking, running
> a basic autopilot test (open, close, put to background, put to
> foreground, whilst not generating crashes)
> 


-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature