ubuntu-phone team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

On Tue, Mar 11, 2014 at 11:08:36AM -0400, Pat McGowan wrote:
> We have identified an issue in click when the same app was both
> pre-installed and updated from the store. A fix is in the works.

Right.  Here's an explanation for posterity, since this is not at all
obvious.

Click maintains multiple databases of packages, which are associated
with the different ways in which a package can be installed.  The
default setup has a "core" database for the packages that are
preinstalled in the stock Ubuntu image, a "custom" database for packages
that are preinstalled by carriers/OEMs, and a "default" database for
user-installed packages.  It's possible for the same package to exist at
more than one version: for example you might have an older factory
version with a newer version that you upgraded from the store; and it's
possible for different users of a single system to "register" different
versions of a package, so that if I upgrade a package on my tablet then
my wife can choose whether she wants to upgrade rather than being forced
to do it at the same time, etc.  This is generally quite flexible.

However, up to now it's been possible for the same version of the same
package to be unpacked in different databases.  This isn't an obviously
sensible thing to do deliberately, but it can easily arise if you
upgrade a package from the store and then later upgrade to a system
image that has that same version of the package preinstalled.

In this case, we have a serious semantic problem.  Packages may attach
to "hooks" defined by system packages, which may either be system-level
(apply to all users, generally mediate access to system resources of
some kind and work on files shared by all users) or user-level (apply to
each user independently).  Hooks create symlinks which are named after
the application ID (package name, application name, version).  For a
system-level hook, what should the symlink point to if there's more than
one unpacked copy of the same version of the same package?  Usually it
doesn't matter - they're the same thing, after all - but in the case of
the apparmor hook it is vitally important that this be self-consistent
and consistent with how all users launch the application, because the
apparmor hook uses the target of the hook symlink as an input to the
profile it generates to grant the application read access to its own
files.  The result of getting this wrong is that the application cannot
read its own files and thus cannot start.

I have instituted a new rule that the deepest of any unpacked copies of
the same version of the same package will always be used.  This is a bit
counterintuitive because normally shallower databases win so that users
can override preinstalled packages, but in this case it's the best
choice because it allows us to eventually garbage-collect old unpacked
copies from user data and thus save valuable space.  This will land in
click 0.4.18.x shortly.

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]