ubuntu-appstore-developers team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

I understand that the world couldn't stop while I was away :-), but it's
unfortunate that this branch was merged when I was on holiday and didn't
have the opportunity to comment on the fundamental design issues around
preinstalled click packages, which is an item on my near-term to-do list
to improve (it wasn't a priority for the IoM demo and then I was at
DebConf and then on vacation).

I'm afraid I think this branch takes quite the wrong approach and should
be reverted for reconsideration, preferably as soon as possible before
its behaviour becomes entrenched.

On Thu, Aug 22, 2013 at 10:29:49PM -0500, Ted Gould wrote:
> On Thu, 2013-08-22 at 22:05 +0000, Loïc Minier wrote:
> > I guess there are a number of different use cases:
> > a) package is in app store but we want to preinstall it
> > b) package is not in app store but we want to preinstall it
> > 
> > and another subcase:
> > 1) package may be removed by end-user
> > 2) package may not be removed by end-user
> > 
> > 
> > 
> > and what we want to decide is whether we're upgrading/reinstalling
> > packages and whether we do this on every boot.
> 
> To be clear, we can't do it on boot because versions are per-user and so
> are hooks that need to be run by the click system.  Also, at boot the
> user's home directory may not be decrypted.

Quite so.

> > Now some conclusions:
> > - it seems clear to me that for a), it doesn't matter whether we
> > update it or not as updates can be delivered from appstore, so we
> > could optionally skip this on boot
> > - it seems natural that things that are in appstore and hence can be
> > installed after the fact should be uninstallable, so that a) should
> > imply 1)
> > - it is obvious that in the case of b), we must update it on each boot
> > - it seems natural that in the case of b), we should not allow removal
> > -- otherwise lets just put it in the appstore
> 
> I think that we can't simplify things like this with the per-user
> installation.  There's no reason both users on a system would have the
> same version of Facebook whether it was pre-installed or not.  It's a
> disk space issue, not an automatic update one.  And, as a user, I could
> not want to update something.

There's really only one decision to take here, and it's whether a
preinstalled package should be upgraded after a system image update.  My
take on this is that, if the user has installed a newer version, then
that should be preserved, but otherwise the preinstalled version should
win.  The solution implemented in this branch has the unfortunate
property that an older version delivered by a system image update will
take precedence over a newer one installed by the user.

There is a straightforward way to implement this which does not involve
doing any work at boot time and not much at session init time, but does
involve some (mostly already planned) extensions to click:

 * change click to support multiple base unpack directories rather than
   just /opt/click.ubuntu.com/ (it's already architected to support
   this, with just a few missing pieces), with system configuration for
   the priority order

 * add a mechanism in click to register an app for all users in a
   particular base unpack directory (which would update the symlinks in
   e.g. /usr/share/preinstalled-apps/.click/all-users/APP/ - note that
   this does not require knowing the set of users on the system from
   recovery mode)

 * add a hook to the system image update mechanism that runs in recovery
   mode (NOT at boot time or in the user session) that does this
   register-for-all-users step for all preinstalled apps

 * we can't entirely do without running code in the user session, since
   we need to do things like creating .desktop files; so at session init
   time, check whether there are newly-registered versions of
   preinstalled apps, and if so then run their hooks

 * if a user installs a new version of an app, it is unpacked into the
   last unpack directory in the priority order (probably still
   /opt/click.ubuntu.com/), and automatically shadows the preinstalled
   version on the system partition for that user

 * if a user removes an app which they had upgraded from the
   preinstalled version, it is removed from their symlink farm in
   /opt/click.ubuntu.com/.users/, the unpacked copy of the app is
   removed if no other users refer to it, and click automatically falls
   back to the preinstalled version on the system partition

I still need to flesh out some details, but IMO this is far more elegant
and robust, and is definitely less wasteful of disk space.  It has the
additional benefit that click automatically has all the metadata about
which apps came from where, and so can inform the UI about things like
whether an app may be removed.

> > So what I'd propose is followings:
> > * /usr/share/preinstalled/click and /custom/preinstalled/click contain
> > clicks that aren't in the appstore and must be installed or upgraded
> > automatically and can't be removed (no flag to allow this for now, but
> > should add one)

The semantics of these paths as implemented in this branch are entirely
wrong, I'm afraid.  My intent is to provide multiple unpack directories
for apps, some of which can be in a writable location and some not.
This makes a lot more sense than shipping the .click files and then
unpacking them post-boot, which has the effect of using up user space as
well as system space for preinstalled apps.

> > * /opt/click.u.c is prepopulated in the rootfs with appstore packages
> > that we want to install by default but may remove, but is never
> > upgraded (which I think is what happens with writable pathes?)
> 
> Hmm, I don't think that we should have paths hard coded anywhere but in
> the click package.  So this is, in my opinion a strong vote for putting
> any upstart job in the click package directly.

I agree.  For the time being, anything outside the click package that
thinks it needs to care about full paths needs special dispensation from
me, as it's probably wrong and may well cause problems.

> > We should add a flag for packages that can't be removed (both for
> > appstore and preinstalled packages).
> 
> Wouldn't they be on a read-only partition?  Isn't that "can't be
> removed" enough?  :-)

Yes, with the exception that we need some work at the UI layer to avoid
offering a removal option that won't work.

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]