Surviving Rolling Releases
I believe that after I started regularly using Linux, I ran a stable release for about 3 months before I started to track rolling releases. There are a few different reasons to make such a decision, whether it be to simply get the newer software packages, or to enjoy the myriad wonders of bug reporting. I do it because I work on software projects of all shapes and sizes and prefer to not work with packages that have already been patched and changed. I’ve used or toyed with Archlinux, gentoo, openSUSE tumbleweed, Debian Sid, and a few others.
Regardless of what distribution I’m using, I’m going to have some source-directories that are tied to git repos. It’s such a big part of how I build my user-space that I have scripts for the dedicated purpose of keeping these libs’ and programs’ directories updated to the main branch and that notify me of changes made to each of them. Regardless of the fact that I’m currently running Debian Sid, I have more userspace built from source than from dpkg. This, as you might imagine, is courting disaster in some aspects. Instability is an expected side-effect, but there are some ways to pad yourself from many of the issues that tend to arise with tracking rolling releases.
1). RTFM: This should go without saying, but the ability to do your own research is a prerequisite to being able to figure out why patches may require you to make some changes to something that you currently use. Release notes and upgrade notices are written to protect you from being totally blindsided by any foreseeable issues that may arise. I was always amused while using Archlinux at the amount of “Help, pacman broke my _____!” posts on their forums the few weeks after some major changes that would be clearly documented on their website’s front page. If you can’t be bothered by reading a few sentences before doing a full system update, then stable releases are more suited for you.
2). Minimize dependencies: While I’m a fan of removing abstractions from Unix-based systems for a few reasons, this one is high on the list. The less things that you have to break, the less chances you have that something will be broken. While it’s tempting to download every single new package and tarball that you read about, in essence, you’re simply increasing the chances that some minor change will directly affect you. I especially appreciate the Debian “recursive negative dependency” issues that arise from time to time. Most recently, an update to perl decided that it would be best to remove xorg from all systems that were using perl and were updated (read: ‘practically all of them’). This may seem like an extreme example, but on a no-X or FB-build, this still doesn’t directly cause issues. gtk-3 is notoriously quirky in Sid, and I feel that unless I’m working on something that uses gtk-3, then these issues are best avoided.
3). Use things that you understand: This one applies far more to source-based packages, repository pushes, and other things that you have direct control over. The ability to diff changes made to source to see what they are changing upstream is extremely useful for source-based packages. As I alluded to earlier, up to 50% of my user-space is built from source repositories, so if a major change has taken place, I probably want to see what it is. Also, I’m accustomed to migrating source that I wish to modify for my own purposes to a separate directory that isn’t tied to a branch so that if I hack in some changes that would apply only to me (such as changing configurations or adding a few features that aren’t appropriate for everyone). Knowing what changes have been made upstream must still be built, and possibly added as a patch to my hacked-up source. This is only as useful as your understanding of what the program or library does, and the language that it’s written in. It does no good to receive information that doesn’t make sense to you. Perhaps this is another plea for not adding a huge set of dependencies as well, but it’s very valid.
These basic 3 rules have served me very well. I’m not saying that it’s all been perfect. Things sometimes get broken when you are staying as up-to-date as possible. What it does accomplish is to keep you well informed about what is actually happening to the software that you’re running. You can’t possibly know every change to every package that exists, but you should at least strive to understand your own system as far as possible. To create a metaphor, it’s okay to not be a plumber, but you at least need to know how to shut off the water in your own house should a leak occur.