ubuntu-appstore-developers team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

[Initially sent to ubuntu-appstore-devel instead of
ubuntu-appstore-developers.  Apparently typing is hard.]

I uploaded click 0.2.2 earlier this evening, and later 0.2.3.  Between
them, these uploads fix a few bugs that Steve Beattie and I noticed
between us while working on hooks, but more importantly they add a
user-level hook to create desktop files.  With this, you can install
Click packages and appropriate desktop files will be created in
~/.local/share/applications/, like this:

  $ pkcon -p install-local research/click_packages/com.ubuntu.calendar_0.4_all.click
  Transaction:    Simulating install
  Status:         Waiting in queue
  Status:         Starting
  Status:         Running
  Transaction:    Installing files
  Status:         Waiting in queue
  Status:         Waiting for authentication
  Status:         Waiting in queue
  Status:         Starting
  Status:         Running
  Results:
  Installed    com.ubuntu.calendar-0.4

  $ cat ~/.local/share/applications/com.ubuntu.calendar_calendar_0.4.desktop
  # Generated by "click desktophook"; changes here will be overwritten.
  [Desktop Entry]
  Encoding = UTF-8
  Version = 1.0
  Type = Application
  Terminal = false
  Exec = aa-exec -p com.ubuntu.calendar_calendar_0.4 qmlscene calendar.qml
  Icon = calendar64.png
  Name = Calendar
  X-Ubuntu-Touch = true
  X-Ubuntu-StageHint = SideStage
  X-Ubuntu-Gettext-Domain = calendar-app

  Path = /opt/click.ubuntu.com/com.ubuntu.calendar/0.4

As you can see:

 * The Exec entry is mangled to apply the AppArmor profile, which will
   be "unconfined" if there is no apparmor hook defined in the app (I
   plan to restrict this somehow, but from previous discussions the
   security team appears happy for this to be handled by manual review
   at least for the moment).

 * A Path entry is inserted so that the app runs with its current
   directory set to the package unpack directory.  This should allow
   most uses of relative paths to behave reasonably.

This will not work sensibly if the AppArmor hook isn't run, so I hope
Steve manages to get that landed tonight!

The result of this may well be that the core apps preinstalled in the
image as Click packages start taking precedence in the apps
scope/whatever-it-is over those preinstalled as .debs, or possibly that
we get both .deb and Click variants.  Autopilot may well have no idea
how to test the Click versions, and there could be other odd
side-effects.  I've therefore disabled Click package installation in
tomorrow's images (CCing Oliver and Sergio FYI) as a precautionary
measure.  That shouldn't be a regression since as far as I know the
packages preinstalled that way weren't actually used for anything up to
now; they were just for testing.  We can reasonably test behaviour
related to Click packages just by installing them post-boot for the
moment.

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]