Bug#746972: apt-get dist-upgrade will remove packages if new dependency not available
Package: apt
Version: 0.9.7.9
Severity: normal
Summary
-------
apt-get dist-upgrade will remove packages if an update to an installed
package is available which has a dependency that is not available in
the package archive.
Put another way, should updated packages which have dependencies that
are not available in the package repository result in the removal of the
already installed package, as opposed to holding it back (similar to
apt-get upgrade)?
Background
----------
In order to install security updates automatically on a daily basis [1],
we use cron-apt configured to only use the security package repository::
# cat /etc/cron-apt/action.d/5-install
autoclean -q -y
dist-upgrade -q -y \
-o APT::Get::Show-Upgraded=true \
-o
Dir::Etc::sourcelist=/etc/apt/sources.list.d/security.sources.list \
-o Dir::Etc::sourceparts=nonexistent \
-o DPkg::Options::=--force-confdef \
-o DPkg::Options::=--force-confold
# cat /etc/apt/sources.list.d/security.sources.list
deb http://security.debian.org/ wheezy/updates main
deb http://security.debian.org/ wheezy/updates contrib
This configuration has worked flawlessly for years without issue, until
last week [2].
Last week there was a security update for openjdk-6-jre-headless, where
the new version had a new dependency (liblcms2-2). The new dependency
was not available as it wasn't in the security package repository.
Instead of holding back the currently installed packages, dist-upgrade
decided it was better to remove the package altogether, and all reverse
dependencies followed...
For reference, I've included the output of Debug::pkgProblemResolver=yes
below.
[1] http://www.turnkeylinux.org/docs/automatic-security-updates
[2] https://github.com/turnkeylinux/tracker/issues/202#issuecomment-41690093
Is this a bug?
--------------
- User error: Is our security updates mechanism flawed? If so, how do
others perform automatic security updates on production deployments?
- Policy: Security updates are usually backported AFAIK, but in the
above situation it seems this was a version bump, adding a new
dependency. In cases like these, should the new dependency have been
added to the security repository?
- dist-upgrade: Should updated packages which have dependencies that are
not available in the package repository result in the removal of the
already installed package, as opposed to holding it back (similar to
apt-get upgrade)?
Output of pkgProblemResolver
----------------------------
# apt-get dist-upgrade \
-o Debug::pkgProblemResolver=yes \
-o APT::Get::Show-Upgraded=true \
-o Dir::Etc::sourcelist=/etc/apt/sources.list.d/security.sources.list \
-o Dir::Etc::sourceparts=nonexistent \
-o DPkg::Options::=--force-confdef \
-o DPkg::Options::=--force-confold
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Starting
Starting 2
Investigating (0) openjdk-6-jre-headless [ amd64 ] <
6b27-1.12.6-1~deb7u1 -> 6b31-1.13.3-1~deb7u1 > ( interpret
ers )
Broken openjdk-6-jre-headless:amd64 Depends on liblcms2-2 [ amd64 ] <
none > ( none )
Investigating (0) openjdk-6-jre [ amd64 ] < 6b27-1.12.6-1~deb7u1 ->
6b31-1.13.3-1~deb7u1 > ( interpreters )
Broken openjdk-6-jre:amd64 Depends on openjdk-6-jre-headless [ amd64 ] <
6b27-1.12.6-1~deb7u1 -> 6b31-1.13.3-1~
deb7u1 > ( interpreters ) (= 6b31-1.13.3-1~deb7u1)
Considering openjdk-6-jre-headless:amd64 2 as a solution to
openjdk-6-jre:amd64 0
Holding Back openjdk-6-jre:amd64 rather than change
openjdk-6-jre-headless:amd64
Investigating (0) openjdk-6-jdk [ amd64 ] < 6b27-1.12.6-1~deb7u1 ->
6b31-1.13.3-1~deb7u1 > ( devel )
Broken openjdk-6-jdk:amd64 Depends on openjdk-6-jre [ amd64 ] <
6b27-1.12.6-1~deb7u1 -> 6b31-1.13.3-1~deb7u1 >
( interpreters ) (= 6b31-1.13.3-1~deb7u1)
Considering openjdk-6-jre:amd64 0 as a solution to openjdk-6-jdk:amd64 -1
Holding Back openjdk-6-jdk:amd64 rather than change openjdk-6-jre:amd64
Try to Re-Instate (1) openjdk-6-jre-headless:amd64
Investigating (1) openjdk-6-jre-headless [ amd64 ] <
6b27-1.12.6-1~deb7u1 -> 6b31-1.13.3-1~deb7u1 > ( interpret
ers )
Broken openjdk-6-jre-headless:amd64 Depends on openjdk-6-jre-lib [ amd64
] < 6b27-1.12.6-1~deb7u1 -> 6b31-1.13.
3-1~deb7u1 > ( interpreters ) (= 6b27-1.12.6-1~deb7u1)
Considering openjdk-6-jre-lib:amd64 2 as a solution to
openjdk-6-jre-headless:amd64 2
Removing openjdk-6-jre-headless:amd64 rather than change
openjdk-6-jre-lib:amd64
Investigating (1) ca-certificates-java [ amd64 ] < 20121112+nmu2 > ( java )
Broken ca-certificates-java:amd64 Depends on openjdk-6-jre-headless [
amd64 ] < 6b27-1.12.6-1~deb7u1 -> 6b31-1.
13.3-1~deb7u1 > ( interpreters ) (>= 6b16-1.6.1-2)
Considering openjdk-6-jre-headless:amd64 2 as a solution to
ca-certificates-java:amd64 2
Broken ca-certificates-java:amd64 Depends on java6-runtime-headless [
amd64 ] < none > ( none )
Considering openjdk-6-jre-headless:amd64 2 as a solution to
ca-certificates-java:amd64 2
Or group remove for ca-certificates-java:amd64
Try to Re-Instate (1) openjdk-6-jre:amd64
Investigating (1) openjdk-6-jre [ amd64 ] < 6b27-1.12.6-1~deb7u1 ->
6b31-1.13.3-1~deb7u1 > ( interpreters )
Broken openjdk-6-jre:amd64 Depends on openjdk-6-jre-headless [ amd64 ] <
6b27-1.12.6-1~deb7u1 -> 6b31-1.13.3-1~deb7u1 > ( interpreters ) (=
6b27-1.12.6-1~deb7u1)
Considering openjdk-6-jre-headless:amd64 2 as a solution to
openjdk-6-jre:amd64 0
Removing openjdk-6-jre:amd64 rather than change
openjdk-6-jre-headless:amd64
Investigating (1) ant [ amd64 ] < 1.8.2-4 > ( java )
Broken ant:amd64 Depends on default-jre-headless [ amd64 ] < none > ( none )
Broken ant:amd64 Depends on java2-runtime-headless [ amd64 ] < none > (
none )
Considering openjdk-6-jre-headless:amd64 2 as a solution to ant:amd64 -1
Broken ant:amd64 Depends on java5-runtime-headless [ amd64 ] < none > (
none )
Considering openjdk-6-jre-headless:amd64 2 as a solution to ant:amd64 -1
Broken ant:amd64 Depends on java6-runtime-headless [ amd64 ] < none > (
none )
Considering openjdk-6-jre-headless:amd64 2 as a solution to ant:amd64 -1
Or group remove for ant:amd64
Try to Re-Instate (1) openjdk-6-jdk:amd64
Investigating (1) openjdk-6-jdk [ amd64 ] < 6b27-1.12.6-1~deb7u1 ->
6b31-1.13.3-1~deb7u1 > ( devel )
Broken openjdk-6-jdk:amd64 Depends on openjdk-6-jre [ amd64 ] <
6b27-1.12.6-1~deb7u1 -> 6b31-1.13.3-1~deb7u1 > ( interpreters ) (=
6b27-1.12.6-1~deb7u1)
Considering openjdk-6-jre:amd64 0 as a solution to openjdk-6-jdk:amd64 -1
Removing openjdk-6-jdk:amd64 rather than change openjdk-6-jre:amd64
Investigating (1) jenkins [ amd64 ] < 1.535 > ( devel )
Broken jenkins:amd64 Depends on java2-runtime-headless [ amd64 ] < none
> ( none )
Considering openjdk-6-jre-headless:amd64 2 as a solution to
jenkins:amd64 -2
Broken jenkins:amd64 Depends on java2-runtime [ amd64 ] < none > ( none )
Considering openjdk-6-jre:amd64 0 as a solution to jenkins:amd64 -2
Or group remove for jenkins:amd64
Investigating (2) openjdk-6-jre-lib [ amd64 ] < 6b27-1.12.6-1~deb7u1 ->
6b31-1.13.3-1~deb7u1 > ( interpreters )
Broken openjdk-6-jre-lib:amd64 Depends on openjdk-6-jre-headless [ amd64
] < 6b27-1.12.6-1~deb7u1 -> 6b31-1.13.3-1~deb7u1 > ( interpreters ) (>=
6b27)
Considering openjdk-6-jre-headless:amd64 2 as a solution to
openjdk-6-jre-lib:amd64 2
Removing openjdk-6-jre-lib:amd64 rather than change
openjdk-6-jre-headless:amd64
Done
Done
The following packages will be REMOVED:
ant ca-certificates-java jenkins openjdk-6-jdk openjdk-6-jre
openjdk-6-jre-headless openjdk-6-jre-lib
...
Cheers,
Alon Swartz
Reply to: