Comment 2 for bug 1371574

This is quite an interesting problem. I think I've tracked it down to Hook.install_link, which calls DB.get_path to work out where a package lives so that it can set the symlink to point to the right place, and that walks the database from the bottom up. On one level this is clearly wrong; but we have to be careful here, particularly in the area of multi-user support. Consider this situation:

  Initial state:
    /usr/share/click/preinstalled: org.example.foo 1.0, --all-users
    /opt/click.ubuntu.com: org.example.foo 1.1, --user=cjwatson

    This is clear: user cjwatson has upgraded that package from the store, but we are to leave the package at version 1.0 for all other users. There's no conflict as we can simply run system hooks for both org.example.foo 1.0 and org.example.foo 1.1, creating AppArmor profiles for both.

  After system image upgrade:
    /usr/share/click/preinstalled: org.example.foo 1.1, --all-users
    /opt/click.ubuntu.com: org.example.foo 1.1, --user=cjwatson

    Now what do we do? If user cjwatson runs org.example.foo then they will get the version in /opt/click.ubuntu.com, but user cwayne will get the version in /usr/share/click/preinstalled. It's not possible to simultaneously generate both AppArmor profiles; we have to pick one.

I think the proper answer here is probably to resolve versions before running system hooks. In general only the topmost database layer is available for per-user registrations, so it should always be possible to find a topmost path that is common to all users. We can then automatically unregister any conflicting versions above that and use the topmost path for system hooks.