Public bug reported:
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 <roa...@ubuntu.com>
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.
** Affects: xorg-lts-transitional (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xorg-lts-transitional in Ubuntu.
https://bugs.launchpad.net/bugs/1346409
Title:
Installing a package depending on glmark2-es2 attempts to remove a lot
of lts backport packages
Status in “xorg-lts-transitional” package in Ubuntu:
New
Bug description:
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 <roa...@ubuntu.com>
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg-lts-transitional/+bug/1346409/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
