unity-api-bugs team mailing list archive

[Ted Gould <ted@xxxxxxxx>]

On Mon, 2014-07-07 at 13:30 +0000, Martin Pitt wrote:

> That may be, and for speedup reason this might be considered. But it's
> still wrong to rely on the symlinks in ~/.cache:
> 
>  - The user might try and clean up after being low on space, and removing ~/.cache/ is a legitimate thing to do
>  - With --all-users it's in no way guaranteed that you can actually access every user's home directory. They might be encrypted (ecryptfs), or on a remote storage, or you don't even know which users are on the system (LDAP and the like)
> 
> These are certainly not important use cases on today's phone, but they
> are on a desktop, and we are aiming for convergence here I suppose? So
> u-a-l still ought to also look into the click package's --pkgdir IMHO.


I think ~/.cache is a good place :-) We may have to agree to disagree on
this, but here are my arguments.

 - We don't want the symbolic links backed up. Backup utilities like
deja-dup ignore ~/.cache (correctly).
 - The symbolic links are by machines for machines, so they can be
recreated at anytime, so they don't qualify as user data.
 - If for some reason a user did decide to delete their ~/.cache
directory the symbolic links would be recreated on the next login
 - If a package is installed with all-users the symbolic link will be
created the next time a user logs in, before apps could get launched.

In general the reason to use the cache directory at all is an
optimization, we don't want to open up the click database for every
launch of an application to determine its package directory. It's too
expensive. So we use the cache to do just that, provide a cache on how
to launch the app.

I'm not against having a slower path if the cache is determined to be
destroyed or invalid, but I think that'd be a "nice to have" not a
priority feature and would delay starting up of legacy apps so it would
have to have the cost determined (perhaps we don't care about it?).

-- 
You received this bug notification because you are a member of Unity API
bugs, which is subscribed to Ubuntu Application Launcher.
https://bugs.launchpad.net/bugs/1333215

Title:
  "Unable to find keyfile for application": Does not look for .desktop
  files in click pkgdir

Status in Ubuntu Application Launcher:
  Incomplete
Status in “click” package in Ubuntu:
  New
Status in “ubuntu-app-launch” package in Ubuntu:
  Incomplete

Bug description:
  For testing/autopkgtest I want/need to run click apps and their tests
  in a schroot or container, as the turnaround with real phones and the
  emulator is way too large. But in a container, ubuntu-app-launch fails
  with

  $ ubuntu-app-launch `ubuntu-app-triplet com.ubuntu.calculator`

  ** (process:766): WARNING **: Unable to find keyfile for application 'com.ubuntu.calculator_calculator_1.3.283'
  init: application-legacy (com.ubuntu.calculator_calculator_1.3.283-1403523098604203) pre-start process (770) terminated with status 1

  In strace I see that it looks for the .desktop file in the following
  locations:

    /home/ubuntu/.cache/ubuntu-app-launch/desktop/com.ubuntu.calculator_calculator_1.3.283.desktop
    /home/ubuntu/.local/share/applications/com.ubuntu.calculator_calculator_1.3.283.desktop
    /usr/local/share/applications/com.ubuntu.calculator_calculator_1.3.283.desktop
    /usr/share/applications/com.ubuntu.calculator_calculator_1.3.283.desktop

  but not in the click dir:

  $ click pkgdir com.ubuntu.calculator
  /opt/click.ubuntu.com/.click/users/@all/com.ubuntu.calculator

  The workaround is to create the symlink manually, then it works:

  $  ln -s `click pkgdir com.ubuntu.calculator`/*.desktop .cache/ubuntu-app-launch/desktop/`ubuntu-app-triplet com.ubuntu.calculator`.desktop
  $ ubuntu-app-launch `ubuntu-app-triplet com.ubuntu.calculator`

  But that's certainly not something that autopkgtest should do.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-app-launch/+bug/1333215/+subscriptions