Comment 6 for bug 1318084

OK, I think I found it:

  Installing glmark2-es2 as Recommends of plainbox-provider-certification-client
    Installing libgles2-mesa as Depends of glmark2-es2
      Installing libglapi-mesa as Depends of libgles2-mesa

this libglapi-mesa thingy is provided by libglapi-mesa-lts-saucy, which is part of the enablement stack. Relevant data from that package:

Package: libglapi-mesa-lts-saucy
Version: 9.2.1-1ubuntu3~precise1
Replaces: libglapi-mesa
Provides: libglapi-mesa, xorg-renamed-package, xorg-renamed-package-lts-saucy
Conflicts: libglapi-mesa, xorg-renamed-package-lts-quantal, xorg-renamed-package-lts-raring

As seen, it correctly replaces/conflicts the vanilla libglapi-mesa package, and provides libglapi-mesa, which should keep dependents happy.

However, our direct dependency (libgles2-mesa) is NOT happy with the 9.2.1 version of libglpi-mesa as provided by the above package. It has this:

Package: libgles2-mesa
Version: 8.0.2-0ubuntu3
Replaces: libgles2
Provides: libgles2
Depends: libglapi-mesa (= 8.0.2-0ubuntu3), libc6 (>= 2.2.5)
Conflicts: libgles2

So it wants a specific version of libglapi-mesa, thus causing:

- Replacement of libglapi-mesa-lts-saucy with libglapi-mesa (as seen in the attached problemresolver output)
- Installing libglapi-mesa on its own results on removal of the same packages shown in the original report, i.e. destroying the entire saucy enablement stack and ubuntu-desktop which depends on it.

When installing via plainbox-provider-certification-client, that's what happens. Next I'll look at why installing the dependencies manually doesn't cause things to break.