On 12/16/2013 10:05 AM, Dimitri John Ledkov wrote: > On 16 December 2013 15:27, Jamie Strandboge <ja...@canonical.com> 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/
signature.asc
Description: OpenPGP digital signature
-- 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
