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 -- Mailing list: https://launchpad.net/~unity-api-bugs Post to : unity-api-bugs@lists.launchpad.net Unsubscribe : https://launchpad.net/~unity-api-bugs More help : https://help.launchpad.net/ListHelp
