Cannot provide multi-arch click packages for scopes

[dobey]

Currently, click packages with scopes cannot provide the same scope for multiple architectures, as the hook takes the directory name that the scope is in, but does not support the .so for the scope being in a sub-directory based on the arch triplet.

[Launchpad Janitor (janitor)]

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

[Michi Henning (michihenning)]

unity-scopes-api supports multi-arch because scopes are installed in arch-specific directories. For example: /usr/lib/x86_64-linux-gnu/unity-scopes/musicaggregator/

Is this an issue with click?

[dobey (dobey)]

It supports debian-packaged scopes that are installed in the system directories just fine. I don't think this is a problem with click itself, but with the scoperunner. As it is right now, the scoperunner requires the scope .ini file and .so file to both be in the same directory, and in the case of scopes which are packaged as clicks, only that one directory can be specified as the "scope" in the manifest.json for the package. The hook then creates a symlink to that directory in ~/.local/share/unity-scopes/ from where the scope gets loaded. I think to fix the, the part of the unity-scopes-api code which resolves the path to the .so, will need to support arch-specific sub-directories within the directory that contains the .ini file, or to have multiple .so files in the same directory, each with its target platform as part of the filename.

[Michi Henning (michihenning)]

"It supports debian-packaged scopes that are installed in the system directories just fine."

Not sure what you mean by "it", click or unity-scopes-api? Presumably, unity-scopes-api?

The scoperunner expects to be told what the scope's .ini file is. The .ini file and the .so need to be in the same single directory. That's it. The scoperunner can deal with different architectures just fine. If we want to install the same single scope three times for different architectures on the same machine, that's not a problem: install the scope three times in three different directories, each containing the .so and the .ini file.

It seems there is a problem with the manifest for scopes rather than the scopes run time?

[dobey (dobey)]

On Fri, 2014-12-05 at 03:44 +0000, Michi Henning wrote:
> Not sure what you mean by "it", click or unity-scopes-api? Presumably,
> unity-scopes-api?

Sorry, yes, unity-scopes-api.

> The scoperunner expects to be told what the scope's .ini file is. The
> .ini file and the .so need to be in the same single directory. That's
> it. The scoperunner can deal with different architectures just fine. If
> we want to install the same single scope three times for different
> architectures on the same machine, that's not a problem: install the
> scope three times in three different directories, each containing the
> .so and the .ini file.

But this is only valid for scopes which are not packaged as clicks. For
scopes packaged as clicks, you can only have on directory with one .ini
file and one .so in it. Also, the .ini file is not architecture
dependent, so having to include N exact copies of the file in different
locations, just for different architectures, seems like a bad solution.
The scope cannot be installed in three different places from click
packages right now. The hook only supports one scope directory. Thus, it
only supports one architecture per click package. This is the problem.

> It seems there is a problem with the manifest for scopes rather than the
> scopes run time?

I don't think this is a problem with the manifest. Unless you're
suggesting that the way hooks work needs to be changed, but this still
would require changes on the unity-scopes-api side.

[Michi Henning (michihenning)]

The .ini file *is* architecture dependent, because it allows a custom
scoperunner to be used, and that scoperunner is architecture dependent.

If click supports only one architecture per package (which strikes me as a
good thing, BTW), that would seem to make it a click issue?
scopes-api doesn't care about *how* things get installed, and it has
nothing to do with the hooks.

Why would we want more than one architecture in a
single click? I'd be downloading a bunch of binaries
(possibly over the cell network) every time I install something. To what end?

As far as unity-scopes-api is concerned, it's entirely fine to have multiple
architectures in the file system. Everything that is architecture dependent
is already in separate locations, so none of the arch-specific files overwrite
each other. So, I just don't see what we would change in scopes-api or how.

[dobey (dobey)]

On Fri, 2014-12-05 at 22:21 +0000, Michi Henning wrote:
> The .ini file *is* architecture dependent, because it allows a custom
> scoperunner to be used, and that scoperunner is architecture dependent.

Can you point me to where that is documented or the code that does it? I
do not see any arch dependent keys in the documentation at
http://developer.ubuntu.com/api/scopes/sdk-14.10/index/#deployment that
would support this.

> If click supports only one architecture per package (which strikes me as a
> good thing, BTW), that would seem to make it a click issue?
> scopes-api doesn't care about *how* things get installed, and it has
> nothing to do with the hooks.

Click itself does support multiple architectures per package. Which is
why I say this is not a click issue. The scope hook is handled by
unity-scopes-api and only supports a single scope directory, thus
unity-scopes-api only supports a single architecture for scopes in click
packages.

> Why would we want more than one architecture in a
> single click? I'd be downloading a bunch of binaries
> (possibly over the cell network) every time I install something. To what end?

This is how click works. Otherwise, developers will need to build a
separate package for each architecture and upload it to the store, with
a different package name.

> As far as unity-scopes-api is concerned, it's entirely fine to have multiple
> architectures in the file system. Everything that is architecture dependent
> is already in separate locations, so none of the arch-specific files overwrite
> each other. So, I just don't see what we would change in scopes-api or how.

The problem is exactly that we can't have multiple architectures on the
file system, due to the way the scopes installed via click packages
work. Either we need to change how the hook works (which may need
changes in click and click-reviewer-tools as well), or we need to change
how scoperunner works. Or are you saying that a layout as follows is
possible?

~/.local/share/unity-scopes/com.example.scope_scope/
~/.local/share/unity-scopes/com.example.scope_scope/arm-linux-gnueabihf/
~/.local/share/unity-scopes/com.example.scope_scope/i386-linux-gnu/
~/.local/share/unity-scopes/com.example.scope_scope/x86_64-linux-gnu/

Each of those 3 sub-directories having a scope.so and
com.example.scope_scope.ini in them?

If so, then the documentation on how to package the scope will need to
be updated. The documentation currently implies that won't work. I don't
know the code well enough to know if it will work or not, and I haven't
tried to do it myself.

[Michi Henning (michihenning)]

> Can you point me to where that is documented or the code that does it? I
> do not see any arch dependent keys in the documentation at
> http://developer.ubuntu.com/api/scopes/sdk-14.10/index/#deployment that
> would support this.

Check out CONFIGFILES in the root dir of the unity-scopes-api tree. It lists all the config attributes.

My apologies, we are still lagging behind with the documentation for this.

The registry looks for click scopes in $HOME/.local/share/unity-scopes (unless the dir is changed in the Registry.ini file).
In there, it expects to find scope installation directories. Given that these aren't real directories, but symlinks, I would expect click to create the symlink to point at the correct architecture-specific directory.

So, if click does indeed support installing multiple architecture binaries, all it needs to do is make sure that the symlink points at the correct directory.

> The scope hook is handled by unity-scopes-api and only supports a single scope directory

I honestly don't know what you mean by this. As far as I know, we have nothing to do with the hook. I don't believe there is any hook code in our tree.

[dobey (dobey)]

Add the Ubuntu RTM distro and the c-d-s-i tracking project, as I think we should fix this in RTM as well. Hopefully we can get it targeted to an update milestone soon, and get it out to devices.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity-scopes-api - 0.6.10+15.04.20141210.2-0ubuntu1

---------------
unity-scopes-api (0.6.10+15.04.20141210.2-0ubuntu1) vivid; urgency=medium

  [ Marcus Tomlinson ]
  * Renamed "Tags" scope .ini option to "Keywords".
  * Added support for IsAggregator scope .ini option.

  [ Pawel Stolowski ]
  * Pass partner-id via UserAgent with remote-scopes call (LP: #1389273).
  * Implemented BufferedResultForwarder API.
  * Allow multi-arch click packages for scopes (LP: #1398998).
  * Use SIGNON_POLICY_NO_USER_INTERACTION by default unless UNITY_SCOPES_OA_UI_POLICY
    is set (LP: #1380914).

  [ Ubuntu daily release ]
  * debian/libunity-scopes3.symbols: auto-update to released version
 -- Ubuntu daily release <email address hidden> Wed, 10 Dec 2014 12:59:48 +0000