Merge lp://qastaging/~roadmr/checkbox/packaging-canonical-certification-server-updates into lp://qastaging/~checkbox-dev/checkbox/checkbox-packaging

I'm confused... does this mean the providers will no longer provide the binaries to launch plainbox? So anyone who wishes to create a provider and provide a binary to launch the harness will also need to submit code to checkbox-ng?

Or is this just to work around a temporary issue?

I agree with Jeff, I think canonical-cert-server binary should be part of of canonical-cert-server.

A provider should not only provide whitelists and tests, but the ability to quickly run those.

I am thinking here about the CE QA use case, for example.

Let's think this way:

Elsa, who is the QA lead for Lenovo, works for a while in creating the Sutton provider with the specific tests for Sutton (plus she knows all certification tests need to run as well).
She creates a new provider with a whitelist with the lenovo tests and pointing to all cert tests.
She creates a binary that runs checkbox-gui with that whitelist
She packages the provider (including the binary) and adds extra dependencies if needed (i.e. certification provider)

Then, all CE QA members testing a Lenovo system, only need to do:

$ sudo apt-add-repository ppa:sutton-2014-testing
$ sudo apt-get update
$ sudo apt-get install sutton-2014-testing
$ sutton-2014-testing

withtout knowing anything about the complexity of dependencies.

Apparently this merge request goes against the current of existing plans:

09:39 <@spineau> roadmr: I really want to delete the binaries from checkbox-ng
                 so that we can host them in the relevant providers

This is what Ara and Jeff want, and apparently it's the intended plan. Sylvain said:

09:44 <@spineau> roadmr: for short term I'd vote for your MR to restore ccs
                 installation but ideally checkbox-ng should support profiles
                 like checkbox-gui, not positional arguments

So having c-c-s be installable and depend on correct stuff (for the time being) is a desirable goal. A possibility is this:

09:46 < roadmr> spineau: ok, I'll see if I can find another alternative. Maybe
                even introducing another package (c-c-s-interim) that installs
                checkbox-ng and the provider would be cleaner and easier to
                revert later
09:46 < roadmr> c-c-s-interim could Breaks: c-c-s (so it gets removed for the
                time being) and Depends: checkbox-ng provider
09:47 < roadmr> then when we make everything right again, c-c-s Breaks:
                c-c-s-interim to start deprecating it

I'll read a bit on debian packaging and think about the implications of this interim package (to be clear, it'd be a very temporary solution while everything else coalesces and stabilizes) and come up with a better fix.

Rejecting per above conversation.