Code review comment for lp:~sergiusens/ubuntu-touch-session/install_clicks

Revision history for this message
Loïc Minier (lool) wrote :

On Fri, Aug 23, 2013, Ted Gould wrote:
> > 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.
>
> We probably do need something on the user session init to handle the
> case of clicks that are on the image (not writable) and the version has
> been upgraded. This way the per-user click hooks can be run.

This was a fairly broad "on boot"; on session startup works too, and I
agree it's a better choice. +1 on doing this in the session startup.

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

I tried to address these cases; I think it's good enough as a first
iteration. Consider we don't even have click package updates or
removals yet! Let's implement this for now, and iterate on it.

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

Not sure where click.u.c is currently hardcoded; it seems a good idea to
keep things together I agree.

> > 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? :-)

Dont think this relates at all; first, /opt/click.u.c is not r/o but rw
(as you need to be able to install/upgrade/remove packages); second, we
want package updatable by the appstore that can't be user-removed. E.g.
OEM customizations. But that's kind of a longer term problem.

--
Loïc Minier

« Back to merge proposal