touch-packages team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxxxxx>]

I've made some progress on this.  It is all however excruciatingly
delicate, and this is not the first time that I have had to fix bugs of
this general nature.  I'm beginning to wonder if I should be taking a
different approach.  The whole problem here is that system hooks may
only be attached to by a single instance of any given package version;
this leads to the requirement that the AppArmor profile must point to
just the right instance, and we often run into trouble (of the
"launching application results in blank screen" kind) when trying to
move packages around between databases in various ways.  Even with
regression tests, I'm worried that if I whack this mole it's still going
to pop up somewhere else.  It's not clear that all the requirements are
truly soluble given the current design.

A more comprehensive answer to this category of problems, then, would
involve a slight tweak to the design of system hooks, though fortunately
an entirely backward-compatible one:

 * We add a new substitution to the hook Pattern field that expresses which database a package is in (the practicalities seem to suggest that a mangled version of its path would be easiest, so ${db-path} expanding to "usr_share_click_preinstalled" etc.).
 * When this substitution is present, "click hook" would start running system hooks for all instances of every package version.
 * click-apparmor could then add that to its .hook file once it's ready, perhaps becoming "Pattern: /var/lib/apparmor/clicks/${db-path}/${id}.json", or a flat structure if that's easier.  It would need to adjust its handling of /var/lib/apparmor/{clicks,profiles}/ to cope with this, of course, and the first system image upgrade with the new version of click might have to rebuild all profiles on startup unless it's very clever, but that's comparatively minor.
 * Now that profiles depend on the database path, aa-exec-click would need to change its lookup to depend on the click database containing the requested executable.  Some care would be needed to make sure this doesn't slow down application startup and make Ricardo cry; ubuntu-app-launch's desktop hook could perhaps help with this, although that may not be necessary.

The result of this would be much easier to deal with in click, and would
be free of corner cases where there isn't obviously a single correct
answer.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1371574

Title:
  After installing clicks to /custom/click,
  /usr/share/click/preinstalled version are still preferred

Status in “click” package in Ubuntu:
  In Progress

Bug description:
  This occurs while moving click apps from the rootfs into the custom
  tarball.  Because of this some apps fail to launch.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.10
  Package: click 0.4.32.1
  ProcVersionSignature: Ubuntu 3.16.0-10.15-generic 3.16.1
  Uname: Linux 3.16.0-10-generic x86_64
  NonfreeKernelModules: fglrx
  ApportVersion: 2.14.7-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Fri Sep 19 07:53:58 2014
  InstallationDate: Installed on 2013-04-26 (510 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  SourcePackage: click
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/click/+bug/1371574/+subscriptions