ubuntu-appstore-developers team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

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.

> 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).

> 3) On app review, it should be checked that it's not enabled (beuno?)

This should be unnecessary given the above design.

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]