Cannot install click packages on ISO installs of Ubuntu

Status changed to 'Confirmed' because the bug affects multiple users.

As a workaround for now, you install the packages using click install as suggested. You will also then need to use click register to register them under your user.

Caveat: maybe we need to add a OnlyShowIn=Unity8 or something, so the apps don't show up under unity7, where they would run unconfined.

This is on xenial? Or vivid?

Status changed to 'Confirmed' because the bug affects multiple users.

same here, on Xenial

see this bug

@dobey either - pkgcon defaults to dpkg management so fails installing a .click file.

@Emanuele please don't add tasks to bugs if you don't know where the problem lies, especially when you can see we're already working on fixing it.

Well, Xenial is getting the new PackageKit which doesn't support additional plug-ins, so clicks will not be installable there, no matter what is done.

There is nothing unity-scope-click can do about the configuration of packagekit, either. If you want to install clicks on a traditional PC, you will need to alter the the configuration (or install whatever is included on the phone images, which performs that alteration for you).

Why did you mark this as Invalid in click and re-assign to the scope? If any package should do anything about this, it is click itself, not the scope.

There's a branch which removes the PackageKit dependency, which really ought to be landed:

  https://code.launchpad.net/~mvo/click/native-dbus

We will not support installing clicks in the desktop via pkcon, since the desktop is moving to PK 1.0 which no longer supports the click plugin.

Pkcon will remain supported on the phone overlay until the phone images move to snap packages.

why?

We are considering alternate approaches for this bug, so I'm reopening it.

Bringing the bug up to speed. It seems that Xenial is not getting package kit 1.0, so the 0.8 version that has a click backend can remain in Xenial and can be used. And it is in the Xenial archive. So we're all good as far as repositories are concerned. But it doesn't work by default.

This is related to the python3-aptdaemon.pkcompat getting installed, which makes aptdaemon act the PackageKit backend instead of PackageKit itself. You can fix an image by doing "apt install packagekit" which will cause it to be removed. Then PackageKit itself will handle the pkcon commands and install the package correctly.

So that is the first part of this bug, and results in a system that can install Click package correctly. We need to figure out which seeds/packages it makes sense to put the appropriate package dependencies in.

The second part is that by default on the desktop PackageKit is using PolicyKit for a privilege request. Unity8 doesn't currently have a PolicyKit handler. We'll need to add that to the system so that an appropriate prompt can be shown on install.

Xenial got this change

https://launchpad.net/ubuntu/+source/unity-scope-click/0.1.1+16.04.20160318-0ubuntu1

"unity-scope-click (0.1.1+16.04.20160318-0ubuntu1) xenial; urgency=medium

  * Add dependency on packagekit so install of clicks will work on PCs."

it means that installing unity8/unity-scope-click is installing packagekit now (and removing the aptdaemon compat layer) which should make things work. Unity8 still doesn't have the prompting capability needed though it seems, maybe one workaround would be to add a plka file allowing local users to install clicks without have to auth, since clicks don't have access to system directories it's less likely to damage the system so it might be an ok thing to do there?

On, and we still plan to update packagekit at some point (next cycle hopefully) so we still need to make click stop using the deprecated interface...

On Wed, 2016-04-06 at 06:33 +0000, Sebastien Bacher wrote:
> Unity8 still doesn't have the prompting capability needed though it
> seems, maybe one workaround would be to add a plka file allowing
> local users to install clicks without have to auth, since clicks
> don't have access to system directories it's less likely to damage
> the system so it might be an ok thing to do there?
Prompting support up for review:
https://code.launchpad.net/~ted/unity8-policy-kit/initial-work/+merge/2
91371
Security was pretty adamant that it should prompt on a multi-user
system.

Status changed to 'Confirmed' because the bug affects multiple users.