Installing a package depending on glmark2-es2 attempts to remove a lot of lts backport packages

[Daniel Manrique]

I initially found this problem with the plainbox-provider-certification-client package from ppa:checkbox-dev/ppa, but later was able to reproduce it with a minimal, dummy debian metapackage which simply has this in debian/control:

Source: depends-on-glmark2-es2
Maintainer: Daniel Manrique <email address hidden>
Section: misc
Priority: optional
Standards-Version: 3.9.2
Build-Depends: debhelper (>= 9)

Package: depends-on-glmark2-es2
Architecture: all
Recommends: glmark2,
            glmark2-es2
Description: depend on glmark2-es2
 A simple package to glmark2-es2 and enablement stack problems

On Ubuntu releases which include the backported LTS hardware enablement stack, trying to install glmark2-es2 indirectly causes apt-get to want to remove a large set of x-related packages, attempting to replace them with older non-LTS-stack versions, but ultimately in some cases leaving the system unusable due to removal of packages essential to boot to the graphical desktop.

This appears to be because glmark2-es2 has this:

libegl1-mesa (>= 7.8.1) | libegl1-x11, ..., libgles2-mesa (>= 7.8.1) | libgles2

libegl1-x11 and libgles2 are virtual packages provided by some packages in the corresponding enablement stack; however apt-get is not always smart enough to figure this out, and tries instead to install the libegl1-mesa and libgles2-mesa packages, which cause the removal of conflicting packages in the installed stack.

Interestingly, if installed on its own on 12.04.4, apt-get *does* realize that a good solution is to install the corresponding package from the existing stack. Trying to install glmark2-es2 directly (apt-get install glmark2-es2) in 12.04.4 (Saucy enablement stack) correctly installs libgles2-mesa-lts-saucy (http://paste.ubuntu.com/7830857), but this direct installation in 12.04.3 and .2 (Raring and Quantal stacks) also attempts removal of those X-related packages (http://paste.ubuntu.com/7830923/).

Assume $EXISTING_STACK represents the currently-installed-stack's release codename (saucy, raring, quantal).

On 12.04.3 and .2, manually installing libegl1-mesa-lts-$EXISTING_STACK then enables installing glmark2-es2 without problems.

Note that in all cases, if I manually install libgles2-mesa-lts-$EXISTING_STACK and libgles2-mesa-lts-$EXISTING_STACK, installing glmark2-es2 succeeds without strange behaviors.

To reiterate, the main problem I'm seeing is that if a package recommends or depends on glmark2-es2, I get one of two possible behaviors:

1- Attempt to remove many x-stack-related packages (if glmark2-es2 is a recommends).
2- Failure to install due to unsatisfied dependencies (if glmark2-es2 is a depends).

Steps to reproduce:

- Boot a 12.04.4, 12.04.3, 12.04.2 live CD image in "try without installing" mode.
- Enable universe and multiverse
- Try to install a package recommending or depending on glmark2-es2 (try the one mentioned at the beginning, or build the dummy metapackage as described).

What I expected to happen:
- apt-get figures out whether to install libegl1-mesa-lts-$EXISTING_STACK or libgles2-mesa-lts-$EXISTING_STACK and both glmark2-es2 and my package are installed correctly.

What actually happens:
- Either attempt to remove x-related packages, or failure to install with unsatisfied dependencies.

[Timo Aaltonen (tjaalton)]

mesa is backported as-is without renaming these days, so this should not happen anymore, closing