mjhjmtu

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?

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.

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.

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.

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




3. 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 .....

4.

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