ubuntu-appstore-developers team mailing list archive

[Roberto Alsina <roberto.alsina@xxxxxxxxxxxxx>]

On Wed, Jul 31, 2013 at 10:28 AM, Colin Watson <cjwatson@xxxxxxxxxx> wrote:

> On Wed, Jul 31, 2013 at 09:41:19AM +0100, Roberto Alsina wrote:
> > Apparently there should be a flag where apps have to be marked as "do not
> > remove" for preloaded apps by OEMs and such.
> >
> > This triggers a few questions:
> >
> > 1) Do we have a field in the manifest for it? Is it per-app? (colin?)
>
> I don't think this should be a manifest-level property - the very same
> app may be preloaded or available for separate installation depending on
> the device model, so that indicates that it isn't logically a property
> of the app.  Rather, it should be a function of how the app is
> installed.  Here's a sketch of my intended design for this:
>
>  * There should be multiple installation roots, rather than just
>    /opt/click.ubuntu.com/ (this is why I keep banging on about how you
>    mustn't hardcode the predicted paths to packages anywhere outside
>    click).  One of them will still be the "primary" root in that it
>    holds the .click/users/ subdirectory with symlinks to the apps each
>    user has installed.
>
>  * OEM-preloaded apps will go somewhere on the read-only system
>    partition.
>
>  * You can upgrade OEM-preloaded apps to a new version by installing a
>    new version into a writable installation root.  This will re-point
>    the symlink under .click/users/, but leave the old version intact (of
>    course, since it's on a read-only file system).
>
>  * You can remove the upgraded version, which has the effect of
>    re-pointing the per-user symlink to the version in the read-only
>    system partition.  (I believe this matches Android's observed
>    behaviour.)
>
>  * This design does allow a low-level operation where you remove the app
>    from your personal view by removing the per-user symlink.  However,
>    this would not be exposed in the UI.
>


> Are folks OK with this approach?  I've alluded to it in a few places
> before, but I don't think I've spelled it out clearly.
>
>
I am ok with it, the only downside I see to it is the same it has on
Android, in that
when there are updates you end up using 2x the space you should because the
system version can't be removed. That's a *huge* pain in cheap android
phones, BTW.


> > 2) On the app scope, we have to check it so we don't offer the option t
> > remove (alecu?)
>
> This might need a bit of support from click to tell it which
> installation root an app is installed in (a synthetic property added to
> "click list --manifest" or similar).
>
>
Agreed. We need this to be cheap to get because it will affect every time
these apps
previews is loaded.



> > 3) On app review, it should be checked that it's not enabled (beuno?)
>
> This should be unnecessary given the above design.
>

Agreed.