I have been running Debian Unstable (sid) for a few months. The only serious issue I have had is Python3 breaking temporarily during an upgrade, and fortunately I was able to fix it within a day, once the maintainers released a fix.

However, I am trying to avoid such headaches in the future, and am here to ask about best practices for determining when to go ahead with package updates on Debian unstable, and when to wait until bugs are fixed before updating. That is: how can I maintain an updated Debian unstable system, while avoiding as much risk as possible of breaking things during install?

For example, right now, running sudo apt-get update; sudo apt-get dist-upgrade shows me over 200 packages in need of upgrading, and 2 it suggests removing:

The following packages were automatically installed and are no longer required:
  libnfs8 python-subprocess32
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
  libnfs11 libzstd1 python-kiwisolver python-olefile
The following packages will be upgraded:
  apt apt-utils atom-beta base-passwd binutils binutils-common binutils-x86-64-linux-gnu bluetooth bluez bubblewrap
  ca-certificates ca-certificates-java console-setup console-setup-linux cpp cpp-7 dconf-gsettings-backend
  dconf-service e2fslibs e2fsprogs e2fsprogs-l10n evince evince-common fontconfig fontconfig-config g++ g++-7 gcc
  gcc-7 gcc-7-base gcc-8-base geany geany-common gir1.2-glib-2.0 gnome-desktop3-data gtk-update-icon-cache gvfs
  gvfs-bin gvfs-common gvfs-daemons gvfs-libs keyboard-configuration libapt-inst2.0 libapt-pkg-perl libapt-pkg5.0
  libarpack2 libasan4 libatomic1 libavcodec57 libavformat57 libavresample3 libavutil55 libbabl-0.1-0 libbinutils
  libbluetooth3 libboost-atomic1.62.0 libboost-chrono1.62.0 libboost-date-time1.62.0 libboost-filesystem1.62.0
  libboost-iostreams1.62.0 libboost-locale1.62.0 libboost-program-options1.62.0 libboost-python1.62.0
  libboost-regex1.62.0 libboost-system1.62.0 libboost-thread1.62.0 libcairo-gobject2 libcairo2 libcc1-0 libcilkrts5
  libcom-err2 libcomerr2 libcups2 libcupsfilters1 libcupsimage2 libdconf1 libdouble-conversion1 libdw1 libelf1
  libevdocument3-4 libevview3-3 libext2fs2 libfftw3-double3 libfontconfig1 libgcc-7-dev libgcc1 libgegl-0.3-0
  libgfortran4 libgirepository-1.0-1 libglib2.0-0 libglib2.0-bin libglib2.0-data libgnome-desktop-3-17 libgomp1
  libgpg-error0 libgtk-3-0 libgtk-3-bin libgtk-3-common libharfbuzz-icu0 libharfbuzz0b libhdf5-100
  libhttp-negotiate-perl libidn11 libinput-bin libinput10 libitm1 libjs-sphinxdoc libkpathsea6 liblsan0 liblz4-1
  libmpx2 libnm0 libnspr4 libnss3 libopenmpt-modplug1 libopenmpt0 libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0
  libparted-fs-resize0 libparted2 libperl5.26 libpostproc54 libprocps6 libpython-stdlib libpython2.7
  libpython2.7-minimal libpython2.7-stdlib libpython3-dev libpython3-stdlib libqt4-dbus libqt4-declarative
  libqt4-designer libqt4-dev libqt4-dev-bin libqt4-help libqt4-network libqt4-opengl libqt4-opengl-dev
  libqt4-qt3support libqt4-script libqt4-scripttools libqt4-sql libqt4-sql-mysql libqt4-sql-sqlite libqt4-svg
  libqt4-test libqt4-xml libqt4-xmlpatterns libqt5core5a libqt5dbus5 libqt5gui5 libqt5multimedia5 libqt5network5
  libqt5opengl5 libqt5printsupport5 libqt5svg5 libqt5widgets5 libqt5x11extras5 libqtcore4 libqtdbus4 libqtgui4
  libquadmath0 libservlet3.1-java libsoup-gnome2.4-1 libsoup2.4-1 libsqlite3-0 libss2 libstdc++-7-dev libstdc++6
  libswresample2 libswscale4 libtiff5 libtsan0 libtumbler-1-0 libubsan0 libvlc-bin libvlc5 libvlccore9 libvolume-key1
  libvte-2.91-0 libvte-2.91-common libwww-robotrules-perl libxft2 ndiff network-manager nmap nmap-common parted perl
  perl-base perl-modules-5.26 procps python python-apt-common python-matplotlib python-matplotlib-data python-minimal
  python-pil python-tk python-tz python2.7 python2.7-minimal python3 python3-apt python3-crypto python3-dev python3-gi
  python3-minimal qdbus qt4-designer qt4-linguist-tools qt4-qmake qt5-gtk-platformtheme qtcore4-l10n
  qttranslations5-l10n sqlite3 tumbler tumbler-common virtualbox virtualbox-dkms virtualbox-qt vlc vlc-bin
  vlc-plugin-base vlc-plugin-notify vlc-plugin-qt vlc-plugin-samba vlc-plugin-skins2 vlc-plugin-video-output
  vlc-plugin-video-splitter vlc-plugin-visualization xfce4-settings xserver-xorg-input-libinput
234 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 275 MB/275 MB of archives.
After this operation, 5,831 kB of additional disk space will be used.
Do you want to continue? [Y/n]

How would you all determine whether or not these upgrades/removals are safe to go ahead with (i.e. if there are any known bugs that break package installation)?

Ideally, I will not have to read through hundreds of bug report pages every time I want to do an update, but I also don't want to just blindly install all of them without knowing if it's going to break my computer.

Do you actually manually check the bug reports for each individual package, or is there a more efficient way of doing this? When you are maintaining a Debian unstable system, what steps do you take during system-wide updates like this to know when to hold off on updating?

3 Answers 3


I know this is not the answer you are looking for but I think it is the right one:

You don't. You just use Debian stable for this.

If you want to use fresh and up-to-date packages you have to live with the (rare) moments of broken packages. There is no way for package maintainers to check if one of their (many) dependencies has an update that might break they own package, as they would have to look through all the changelogs and also execute tests, because sometimes changelogs are not accurate or complete.

As an alternative you can use debian stable and mix in some packages from unstable if really need an up-to-date version of it. But then you still have to verify that the upgrades of those packages are compatible with your stable system.

You should always be able to roll back to previous versions of packages as long as you don't clear the cache. You could clone your machine, try the update and if your tests are successful you can do the updates on your main machine.

Do you actually manually check the bug reports for each individual package, or is there a more efficient way of doing this? When you are maintaining a Debian unstable system, what steps do you take during system-wide updates like this to know when to hold off on updating?

I don't use unstable for productive systems that need to work and can not afford any downtime. For the unstable systems: I cross my fingers and update. If something does not work as expected I just load my last btrfs-snapshot to roll back my entire system and wait until the problems are fixed upstream.

  • 1
    Advising against sid didn't answer my question, and wasn't really helpful. I know what sid is for, and that there is risk involved, but many people use it for years on home computers without wrecking their systems, and I'm asking them for what specific steps they take to achieve that. ... But I hadn't heard of using btrfs-snapshot to do rollbacks after upgrades, and this was super useful, even if not what I was looking for. So thanks for that.
    – J. Taylor
    Commented Apr 19, 2018 at 13:25
  • "but many use it for years without wrecking their systems" - people say it, but I tend to not believe them, except when they have a small system with only a few packages installed. The other suggestion in my answer is that you can use stable and just mix in the packages you need to be "fresh". Then the risk of things breaking are reduced a lot. Why do you need alpha versions of critical os components when you just want the newest mariadb package? Quote from the other answer: "here's my daily routine" if you can afford to update your system on a daily basis and always cross-check, just do it.
    – frieder
    Commented Apr 19, 2018 at 13:39
  • Mixing stable + unstable packages is not recommended. Again, I already know what sid is for and that it will possibly break someday. But I want to use sid for a variety of reasons such as helping with Debian development by identifying/fixing bugs. There are thousands of people who run unstable, and not all of them are just sitting around with broken systems because there are practices for minimizing the risk of breakage, rather than your bad advice of "cross your fingers and update". The other two answers provided examples of these practices.
    – J. Taylor
    Commented Apr 20, 2018 at 18:10
  • 1
    @frieder amazingly enough many Debian developers run unstable on systems with large numbers of packages installed; in my case dpkg --get-selections | grep install$ | wc -l shows 5731 packages, on a system which has been running mostly unstable for over ten years. Feel free to disbelieve me of course, you’re perfectly allowed to and there’s not much I can do about it beyond providing anecdotal evidence. (Obviously I’m not claiming this is evidence anyone should run unstable, just that it’s possible to do so without wrecking one’s system even on non-trivial systems.) Commented May 2, 2018 at 9:42
  • @StephenKitt i believe you and I want to clarify my comment from earlier: I think you have to distinguish debian developers / package maintainers and "normal" users like sysadmins who just want to work with a system and not invest a significant amount of time. I already wrote, that if you have the time and the knowledge you can have a "stable" debian unstable system, but if you stop updating your system for a longer time or you "just want to install security update xyz" after an alert, then you might end with multiple hours of extra work or a broken system (from my experience)
    – frieder
    Commented May 3, 2018 at 14:36

arochester provided a great answer, so I won't reiterate what's there.

Beyond that though, here's some tips to help figure out what is likely to break:

  1. Always check for bug reports against new kernel, glibc, and libstdc++ versions. Depending on your system, you can probably add whatever SSL library you use, your init system, and possibly a handful of other libraries to this (for example, Qt or GTK libraries if you've got a desktop install). If one of these components has a bug that affects you, it's very probable it will at minimum break something, and possibly take out the entire system. This advice goes not just for Debian users, but anyone using a distribution like Debian Sid.

  2. Double checking apt, dpkg, and other packagemanager packages is generally a good idea too. These aren't as likely to kill your system, but recovery from a system broken because of one of them is pretty difficult (I distinctly remember having to manually recover a couple of systems a few years back when the Gentoo package manager had a bug that wiped the list of user installed packages on an upgrade).

  3. Dumb as this sounds, make sure you reboot after the upgrade completes. Most of the issues I've seen on systems like this arose from having old programs running alongside newer ones.

  4. I would suggest looking at using aptitude if possible. It has an awesome preview mode that will let you see why each new package is being installed, what depends on packages that are being upgraded, and why any packages that are being excluded from the upgrade are being skipped. This information is invaluable for figuring out what's likely to break because of an upgrade. Getting this same information out of apt-get or dpkg requires a bunch of manual work to trace the dependencies.

  • Thanks! I hadn't used the preview mode for aptitude before (and have just been using apt-get for years), and that looks like it will be very helpful.
    – J. Taylor
    Commented Apr 20, 2018 at 5:54

As a longtime sid user, where the possibility of an update breaking the system is a daily risk, here's my daily routine.

  1. In a root terminal with the GUI still running

apt update

apt full-upgrade -d

Now, stop and review carefully what is about to happen. First, look for removals. If anything is to be removed, that is your first and primary sign of danger. If it has been a long while (many days or weeks) since your last update, and you really want to get the system updated, then you need to research any package that is to be removed, using depends and rdepends and the information in Debian packages. Sometimes a package is obsoleted by introduction of a replacement package with a different name, so the prior package can safely be let go. But the more typical case is that a dependency will be broken by other upgraded packages, resulting in removal of something that you/your system needs, and that will break it. So, when you see removals, especially when your system has been updated in the recent past, it's safest and easiest to abort the full-upgrade with a "n", and try again tomorrow when it's (hopefully) safe.

  1. If it looks safe to proceed, answer "y" and let the packages be downloaded.

  2. Ctrl-Alt-F1 to the tty1 console, and log in as root.

systemctl isolate multi-user.target

Someone will soon post that this is not necessary. I'm not so sure. I'm not a software engineer and I don't wish to have any breakage in the xserver and GUI part of my systems. I have three fully updated sid systems that have been running error free since the last time some piece of hardware broke or got upgraded some years ago, so .....


apt full-upgrade

apt clean

systemctl isolate graphical.target && exit

It has happened very rarely that, even with no packages removed, a buggy new package has broken sid systems. But this situation is pretty obvious and the fixed package comes in pretty quickly, so I doubt this would even happen in testing.

Source: http://forums.debian.net/viewtopic.php?f=10&t=131073&p=633270#p633215

  • +1 for actually answering the question instead of advising against sid. I understand what sid is for, and that it's not advised to use it for production/important systems. But I also know there are many users who have run sid for years on their home computers because they know how to properly do upgrades, instead of just blindly installing and hoping for the best. I'm willing to take some risk of this sid system breaking (or I wouldn't be running sid!), but I don't want to unnecessarily break it either. This was helpful. I will read more on using depends/rdepends to check removals. Thanks.
    – J. Taylor
    Commented Apr 19, 2018 at 13:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .