How To Run Debian Sid (Relatively) Safely

As an experiment because VMware Workstation has issues with some of the latest GNU/Linux distributions, I’ve been running Debian Stable, Debian Testing and Debian Unstable. And running Unstable can be extremely interesting if you try to use full-upgrade or dist-upgrade as at the moment it will delete a lot of KDE components and break the system leaving you to log into XFCE. But since Debian Testing is just a few days behind Debian Unstable, it’s an easier option if you want newer than stock Debian that isn’t as easy to break. And with the Xanmod kernel I’m running the latest kernel with all versions, and only a version or two newer than Testing and Unstable. But this write up on running Unstable is pretty good and I learned the Testing repository trick with setting update preferences if an Unstable package is broken. But the main thing is to just use upgrade.

https://linuxconfig.org/how-to-run-debian-sid-relatively-safely


6 June 2020 by Nick Congleton

Debian Sid often scares away new users. It’s called “Unstable” after all, and it’s named after the mean kid in Toy Story that broke all his toys. It’s got to be horrible, right? Well, that’s not the case, most of the time. Sid is no more unstable than the likes of Arch Linux, and with a little planning and common sense, you can run Sid on your desktop with relative safety.

In this tutorial you will learn:

  • How to Set Up Apt-Listbugs
  • How to Avoid Making FrankenDebian
  • How to Use Ubuntu PPAs Sparingly
  • How to Plan Your Upgrades

Use Debian Sid Safely.

Software Requirements and Conventions Used

CategoryRequirements, Conventions or Software Version Used
SystemDebian Sid
SoftwareN/A
OtherPrivileged access to your Linux system as root or via the sudo command.
Conventions# – requires given linux commands to be executed with root privileges either directly as a root user or by use of sudo command
$ – requires given linux commands to be executed as a regular non-privileged user

How to Set Up Apt-Listbugs



Like most rolling-release Linux distributions, Sid doesn’t just brake randomly because it feels like it. Breakage usually comes from a bad update. While there is no true substitute for subscribing to and reading developer mailing lists, not everyone has the time for that. Thankfully, Apt tracks known bugs, and there’s a convenient tool that will tell you if there are any bugs present in your incoming upgrade and allow you to choose to stop it before breaking something.

Apt-listbugs works automatically in the install process. You don’t need to configure anything, and you don’t need to manually run it. Simply install the package, and run your updates as usual. If there is a bug present, apt-listbugs will pause the upgrade, and present you with the bug and the affected package. There, you can choose to continue anyway or stop. It’s almost always a good idea to stop, unless you’re certain the bug is minor an won’t impact your system. From there, you can choose to wait to upgrade your system again, in the hopes that the bug is resolved, or you can use Apt pinning to switch to the Testing version of the package until the bug is fixed. Either way is a solid option, and you should evaluate on a case-by-case basis.

$ sudo apt install apt-listbugs apt-listchanges

Apt-listchanges is another convenient tool that tells you any important changes to a package. It can’t hurt to include that too.

How to Avoid Making FrankenDebian

FrankenDebian is a term coined in the distribution’s own documentation for when users combine multiple Debian releases or even add in Ubuntu repositories. The Debian devs caution against doing it at all, but there are actually instances when it’s perfectly fine to combine releases. It can even bail you out of bugs, like described above.

Debian Testing and Sid often run very closely with one another, unless a release freeze is in progress. Because of this, it’s a good idea to keep the Testing release available on a Sid system and use Apt pinning to prefer Sid. In case you run into a problematic package, you can prefer the version from Testing, avoiding the broken one in Sid until it’s fixed. Generally, broken packages don’t make it into Testing, as the problems are worked out in Sid. A good example of an /etc/apt/sources.list file would look something like the one below.

deb http://ftp.us.debian.org/debian/ sid main contrib non-free
deb-src http://ftp.us.debian.org/debian/ sid main
 
deb http://ftp.us.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.us.debian.org/debian/ testing main

Then, set up your /etc/apt/preferences to pin back Testing.

Package: *
Pin: release a=unstable
Pin-Priority: 1000
 
Package: *
Pin: release a=testing
Pin-Priority: 100

From there, you can add in specific entries from Testing with a Pin-Priority higher than 1000 to prefer them over their Unstable counterparts.

How to Use Ubuntu PPAs Sparingly

Here’s where things get really crazy. You should avoid using Ubuntu PPAs and any repositories designed for Ubuntu whenever possible, but there are instances where it can work. Ubuntu is based on Debian Sid, so software versions in both Sid and the latest two versions of Ubuntu usually match up fairly well. That means that there’s a chance packages in Ubuntu PPAs will be compatible with Sid.

This does not mean that you should go adding all sorts of Ubuntu PPAs to Sid because “Close enough.” It means that if there’s a PPA that houses a single application without a bunch of libraries or dependencies also in it, you can usually use the PPA for the application. The second you start pulling in libraries and new versions of components and dependencies, you’re practically guaranteed to break your system.

Graphical extras like themes and icons are also a good example of when using a PPA on Debian can be okay. A theme isn’t going to come with system libraries. It’s just a theme, and even if it somehow breaks, your system as a whole will be fine.

How to Plan Your Upgrades

Debian Sid follows most of the rules of a rolling-release distribution. When running a rolling-release, there are some general good practice strategies that you should employ to avoid breaking your system when updating. Some of this is Debian-specific, though, since Sid does do things differently. Planning your updates can seriously help you avoid trouble.

Avoid Dist-Upgrade



It might be tempting to use apt dist-upgrade to force more complete updates and stop packages from being held back. Well, those packages are usually held back for a reason, and dist-upgrade makes choices for you, removing packages to make the new ones work. That’s why using it regularly can be a seriously bad idea. One poorly timed dist-upgrade can rip out vital system components and break everything permanently. There’s really no advantage to using it, so just don’t.

Update Regularly

Like most rolling-release distributions, it’s not a good idea to let Debian Sid fall too far out of date. When a rolling distro falls too far behind, there’s bound to be incompatible packages. The leap forward may end up being too much. That can lead to dependency conflicts that can’t be resolved or downright breakage.

Update Sid around once a week to be sure that everything stays current. Of course, the one exception here is a bug. If you see a bug come up from apt-listbugs, you can wait a bit longer or resort to pinning to clear it up.

Avoid Updates Near A Stable Release

There’s another uniquely Debian problem that can pop up with Sid. Before each stable release of Debian, Testing freezes completely for several months, with no new updates. Sid tends to slow down too because the Debian developers are busy preparing the new release. Then, once the new version launches, all of the back changes flood into Testing and Sid. The result is a boatload of instability. Avoid updating Sid for at least a week following a new Debian release. They only come around every two years or so, meaning this isn’t a terribly common problem.

CONCLUSION

Using Debian Sid is a good way to get a rolling-release Debian experience. You’ll generally have newer packages than Ubuntu, but with about the same level of system stability. No strategy is perfect, and it’s always possible for things to go wrong. That’s why this is only ever a good option on desktops, and you should never run Sid on something absolutely mission critical.