#1150427 dist-upgrade does not handle pre-depends

Package:
apt
Source:
apt
Description:
commandline package manager
Submitter:
Piotr Morgwai Kotarbinski
Date:
2026-10-09 19:31:03 UTC
Severity:
normal
#1150427#5
Date:
2026-10-09 14:08:28 UTC
From:
To:
Several ppl using kernel 7.1.13 from `trixie-backports` reported on Debian
Forums that they could not `dist-upgrade` to the newest 7.2.x, see:
https://forums.debian.net/viewtopic.php?t=168439
https://forums.debian.net/viewtopic.php?p=849545#p849545

On Trixie's `apt` 3.0.3, `dist-upgrade` attempts to remove `linux-image-amd64`:
```
# apt list --installed 'linux*'
linux-base-7.1.13+deb13-amd64/now 7.1.13-1~bpo13+1 amd64 [installed,local]
linux-base-amd64/now 7.1.13-1~bpo13+1 amd64 [installed,upgradable to:
7.2.6-1~bpo13+1]
linux-base/stable,now 4.12.1 all [installed,automatic]
linux-binary-7.1.13+deb13-amd64/stable-backports,now 7.1.13-1~bpo13+1 amd64
[installed]
linux-cpupower/now 7.1.13-1~bpo13+1 amd64 [installed,upgradable to:
7.2.6-1~bpo13+1]
linux-headers-7.1.13+deb13-amd64/now 7.1.13-1~bpo13+1 amd64 [installed,local]
linux-headers-7.1.13+deb13-common/now 7.1.13-1~bpo13+1 all [installed,local]
linux-headers-amd64/now 7.1.13-1~bpo13+1 amd64 [installed,upgradable to:
7.2.6-1~bpo13+1]
linux-image-7.1.13+deb13-amd64/stable-backports,now 7.1.13-1~bpo13+1 amd64
[installed]
linux-image-amd64/now 7.1.13-1~bpo13+1 amd64 [installed,upgradable to:
7.2.6-1~bpo13+1]
linux-kbuild-7.1.13+deb13/now 7.1.13-1~bpo13+1 amd64 [installed,local]
linux-libc-dev/now 7.1.13-1~bpo13+1 all [installed,upgradable to:
7.2.6-1~bpo13+1]
linux-modules-7.1.13+deb13-amd64/now 7.1.13-1~bpo13+1 amd64 [installed,local]
linux-sysctl-defaults/stable,now 4.12.1 all [installed]
# apt dist-upgrade
Upgrading:
  libcpupower1  linux-base-amd64  linux-cpupower  linux-headers-amd64  linux-
libc-dev

Installing dependencies:
  linux-base-7.2.6+deb13-amd64  linux-headers-7.2.6+deb13-amd64  linux-
headers-7.2.6+deb13-common  linux-kbuild-7.2.6+deb13

REMOVING:
  linux-image-amd64

Summary:
  Upgrading: 5, Installing: 4, Removing: 1, Not Upgrading: 0
  Download size: 19.9 MB
  Space needed: 78.5 MB / 2,661 MB available

Continue? [Y/n] n
```

On 3.3.3, it just skips `linux-image-amd64`:
```
# apt dist-upgrade
Upgrading:
  libcpupower1  linux-cpupower  linux-libc-dev

Not upgrading:
  linux-base-amd64  linux-headers-amd64  linux-image-amd64

Summary:
  Upgrading: 3, Installing: 0, Removing: 0, Not Upgrading: 3
  Download size: 4,658 kB
  Freed space: 246 kB

Continue? [Y/n] n
```

This seems to be related to `linux-base` package that was upgraded from 4.12 to
4.17 in `trixie-backports` and that kernels 7.2.x *pre-depend* on:
```
# apt policy linux-base
linux-base:
  Installed: 4.12.1
  Candidate: 4.12.1
  Version table:
     4.17~bpo13+1 100
        100 http://deb.debian.org/debian trixie-backports/main amd64 Packages
 *** 4.12.1 500
        500 http://deb.debian.org/debian trixie/main amd64 Packages
        100 /var/lib/dpkg/status
# apt show linux-image-7.2.6+deb13-amd64
Package: linux-image-7.2.6+deb13-amd64
Version: 7.2.6-1~bpo13+1
Priority: optional
Section: kernel
Source: linux-signed-amd64 (7.2.6+1~bpo13+1)
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Installed-Size: 15.4 kB
Pre-Depends: linux-base (>= 4.17~)
```

Installing manually `linux-base` from `trixie-backports` resolves the issue and
after that `dist-upgrade` works as intended:
```
# apt install -t trixie-backports linux-base
Upgrading:
  linux-base  linux-sysctl-defaults

Summary:
  Upgrading: 2, Installing: 0, Removing: 0, Not Upgrading: 23
  Download size: 32.9 kB
  Space needed: 7,168 B / 3,031 MB available
```
(...)
```
# apt dist-upgrade
Upgrading:
  libcpupower1  linux-base-amd64  linux-cpupower  linux-headers-amd64  linux-
image-amd64  linux-libc-dev

Installing dependencies:
  linux-base-7.2.6+deb13-amd64    linux-headers-7.2.6+deb13-amd64   linux-
image-7.2.6+deb13-amd64  linux-modules-7.2.6+deb13-amd64
  linux-binary-7.2.6+deb13-amd64  linux-headers-7.2.6+deb13-common  linux-
kbuild-7.2.6+deb13

Suggested packages:
  debian-kernel-handbook  firmware-linux-free  linux-doc-7.2

Summary:
  Upgrading: 6, Installing: 7, Removing: 0, Not Upgrading: 0
  Download size: 193 MB
  Space needed: 326 MB / 3,031 MB available

Continue? [Y/n]
```

Configured sources during the above testing:
```
deb http://deb.debian.org/debian/ trixie non-free-firmware main contrib non-
free
deb-src http://deb.debian.org/debian/ trixie non-free-firmware main contrib
non-free

deb http://security.debian.org/debian-security/ trixie-security non-free-
firmware main contrib non-free
deb-src http://security.debian.org/debian-security/ trixie-security non-free-
firmware main contrib non-free

deb http://deb.debian.org/debian/ trixie-updates non-free-firmware main contrib
non-free
deb-src http://deb.debian.org/debian/ trixie-updates non-free-firmware main
contrib non-free

deb http://deb.debian.org/debian/ trixie-backports non-free-firmware non-free
contrib main
deb-src http://deb.debian.org/debian/ trixie-backports non-free-firmware non-
free contrib main
```
No priority pinning was configured.

#1150427#10
Date:
2026-10-09 15:55:46 UTC
From:
To:
Hi,

thanks for your report and sorry that I am closing it, but apt works as
configured here and there is nothing much that could be done about that…
let me explain:

Am Fri, Oct 09, 2026 at 04:08:28PM +0200, schrieb Piotr Morgwai Kotarbinski:
[…]
[…]
[…]
[…]
[…]

Yes and no. It has nothing to do with being a pre-depends. It would
happen on a depends, too. The "problem" is this:
[…]
[…]

The new kernel version (which in this case as per usual for the kernel
is a new package, but same difference) from backports that is to be
installed because linux-image-amd64 (from backports, previously
installed from backports, too, enabling upgrades from backports for it)
depends on it. linux-base on the other hand was already installed and is
NOT from backports, so the higher version, the one the newer kernel
depends on, is not the candidate and not selected for installation.

As you have seen different versions of apt react slightly differently to
that. In fact, it depends on the overall system, too, which choice
apt will make, but that will either be
* keep linux-image-amd64
* remove linux-image-amd64

It wont decide (ever) to upgrade a package to backports, just to satisfy
a dependency if not asked explicitly. That is the intended behaviour of
apt with backports after all and why it works on request:

This installs the version from backports, in turn opting you into
upgrades from backports for that package, too, with all the implications
that has on security support and what not.

You do not need to figure out the dependencies yourself. You "just" have
to remember that you once installed 'linux-image-amd64' from backports
(with all dependencies it needed from backports back then) and just
doing that again resolves the problem, too.


This is in no way special to the kernel. Many software packages do gain
new dependencies in newer versions which might require you to pick those
from backports, too, while previously the version in stable was good
enough.

As silly as it sounds, if kernel folks wanted to avoid this, they would
need to "backport" the kernel to trixie by making it work with the 'old'
linux-base. If that is feasible or not is something for the kernel
people to decide.


Other solvers than our default one(s) make different choices. Maybe apt
could provide better ways of understanding why this happens. I think
most people ask themselves "why?" every time apt shows it is removing
something or holding something back, but years of experience tell me
that while it is most of the time (not always!) relatively easy for
a human to explain why something happens, non-humans run into problems
quickly. See for example 'why/why-not' output. In any case, there are
various wishlists open for improvements in that area, so adding yet
another to the pile seems futile hence why I am closing it as not-a-bug
(but a feature and a wish for a better automatic explanation as to why).


Best regards

David Kalnischkies

#1150427#11
Date:
2026-10-09 18:50:10 UTC
From:
To:
Yes that is an intentional fix in 3.1 and newer.

Not a bug. Candidate is 4.12, apt is working correctly.