Comment 7 for bug 1398998

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.