Debian sid keeps breaking

5 min

debian

sid

unstable

apt

aptitude

transitions

package-management

upgrade

apt-listbugs

apt-listchanges

TL;DR

Running Debian unstable (sid) during a major transition like last years t64 isn’t broken — it just needed babysitting. Use the minimal upgrade pattern, inspect before accepting removals, and let patience resolve issues instead of forcing apt to make a descision. Be conservative and dare to wait.

Introduction

People sometimes complain Debian unstable (aka sid) is broken if a transition is underway and they are unable to solve the issues it causes.
It’s not broken. You just need to baby sit it for the time being. Back in 2025 there was a huge transition going on due to the t64-transition, or solving the 2038 Unix timestamp overflow problem. To solve this problem every package had to be rebuild. The reasonable thing to do was the append t64 to each package that got the treatement. And this meant that libfoo became libfoot64 (not libfoot 64, but libfoo t64). And every package and its dependencies had their dependencies updated from libfoo to libfoot64. And as the builds were asynchronous in nature, this caused a massive ripple effect across the landscape. A lot packages got upgraded (or should I say, packages got replaced with t64). I’ve had ~140 packages who want to be upgraded and couldn’t because of reasons. Trying to force it will indeed break your system.

The escape hatch

For as long as I’ve used Debian I upgrade using the following pattern:

aptitude update
aptitude safe-upgrade
aptitude full-upgrade

If you’ve read the upgrade guides of Debian you’ll see this pattern being called the “minimal system upgrade”. In the past I also installed apt, dpkg, aptitude prior to doing the upgrade. But ever since running unstable I let that approach go. Although I might still do it on occasion. Old habits die hard.

Why I prefer this pattern? Because of how apt/apt-get/aptitude handle upgrades. aptitude safe-upgrade and its apt friends apt upgrade and apt-get upgrade will only upgrade packages if they do not remove packages, apt-get upgrade won’t even upgrade a package if there is a new dependency that needs to be installed. apt and aptitude will do so. In order for apt-get upgrade to do the same you need to use --with-new-pkgs.

After you’ve upgraded packages that didn’t remove packages, you can start the more “dangerous” approach: aptitude full-upgrade or dist-upgrade for both apt and apt-get. Now the upgrade process will only show you packages that deserve some more review.
If you cannot upgrade certain packages during a normal upgrade from stable to stable (so from 11 to 12, or 12 to 13 for example), some packages need to be removed to satisfy dependencies. With t64 this was amplified because not all the dependencies are rebuild at the same time. This also happens when there is a Perl transition. So you cannot do it without blindly accepting the changes. You need to wait a few days for things to clear up, for example, my 140 went to 164 and now sit around 100 packages.

You can’t until you can

To give you an example, fwupd doesn’t want to be upgraded because the safe-upgrade options aren’t 100% sure it can, when you inspect the upgrade you’d see it can be upgraded:

The following packages will be upgraded:
  fwupd{b}
The following packages are RECOMMENDED but will NOT be installed:
  udisks2 udisks2:i386
1 packages upgraded, 0 newly installed, 0 to remove and 107 not upgraded.
Need to get 3711 kB of archives. After unpacking 0 B will be used.
The following packages have unmet dependencies:
 fwupd : Depends: libarchive13t64 (>= 3.2.1) but it is not going to be installed
         Depends: libtss2-esys-3.0.2-0t64 (>= 2.3.1) but it is not going to be installed
The following actions will resolve these dependencies:

      Remove the following packages:
1)      libarchive13 [3.7.2-1 (now, testing, unstable)]
2)      libtss2-esys-3.0.2-0 [4.0.1-7 (now, testing, unstable)]
3)      libtss2-mu-4.0.1-0 [4.0.1-7 (now, testing, unstable)]
4)      libtss2-sys1 [4.0.1-7 (now, testing, unstable)]
5)      libtss2-tcti-cmd0 [4.0.1-7 (now, testing, unstable)]
6)      libtss2-tcti-device0 [4.0.1-7 (now, testing, unstable)]
7)      libtss2-tcti-mssim0 [4.0.1-7 (now, testing, unstable)]
8)      libtss2-tcti-swtpm0 [4.0.1-7 (now, testing, unstable)]

      Install the following packages:
9)      libarchive13t64 [3.7.2-1.1 (unstable)]
10)     libtss2-esys-3.0.2-0t64 [4.0.1-7.1+b1 (unstable)]
11)     libtss2-mu-4.0.1-0t64 [4.0.1-7.1+b1 (unstable)]
12)     libtss2-sys1t64 [4.0.1-7.1+b1 (unstable)]
13)     libtss2-tcti-cmd0t64 [4.0.1-7.1+b1 (unstable)]
14)     libtss2-tcti-device0t64 [4.0.1-7.1+b1 (unstable)]
15)     libtss2-tcti-mssim0t64 [4.0.1-7.1+b1 (unstable)]
16)     libtss2-tcti-swtpm0t64 [4.0.1-7.1+b1 (unstable)]

      Upgrade the following packages:
17)     libarchive-dev [3.7.2-1 (now, testing) -> 3.7.2-1.1 (unstable)]

Every removal is countered by an install of the t64 equivalent. This means you can safely upgrade it.

Patience is a resolver strategy

If you are using a development release version, and there is a major transition going on, patience is a correct strategy. Some dependencies may get broken because of a transition, solution: wait a few days. Let the system catch up. Every 6 hrs new packages are pushed and released to unstable. You don’t need to run full-upgrade or dist-upgrade every time or expect everything just works without investigation. Some packages can be upgraded after manual inspection.

But this shows why unstable is called unstable, because you need to tinker a bit to keep it stable (enough) because you can break it if you don’t pay attention. It is advised to check transition tracker, the Debian mailinglist and the Debian package tracker.

Sid is breaking your toys

Sid breaking things is almost a guarantee. The question isn’t if, the question is when. Anyone running unstable should at a bare minimum install apt-listbugs and apt-listchanges. The former will inform you if a package has bugs filed against it, the latter informs you about the changes a package may have. They hook into your upgrade process and allow you to respond to the changes. Either by not installing a package or taking preventive measures.

Debian unstable - the warning is written on the tin.