Moving to Debian

I made the move from Arch Linux to Debian last week. Someone on the CNULUG mailing list asked me about it and I provided the following explanation:

No official support for alternate initsystems (Debian at least has open debate about OpenRC vs Initscripts vs systemD vs Upstart).

[Arch has a r]elatively closed development cycle compared to Debian. It’s hard to follow what the devs are doing, even tracking arch-dev-public and the archlinux mailing list isn’t on par with following the Debian lists.

[Debian’s] wider array of packages mean I have to deal with less of the awful quality of AUR PKGBUILDs. There’s no time spent messing around trying to get it to work because the developer hasn’t updated it in forever. Likewise, there’s no questioning whether or not I can trust the author of the PKGBUILD to be both (a) smart and (b) in my best interest (in terms of security). The debian packages hit a huge number of users, and there is active debate about each and every one of them in the mailing list - the same of which I wouldn’t say for the AUR.

Desire to deviate from upstream. Arch locks their packages to upstream, even if it doens’t make the most sense. Examples include naming the GPG keys produced by mutt. On Arch, they use vanilla mutt so you don’t get the patch that lets your GPG keys be named (e.g. in Gmail) signature.asc instead of noname. This is one little thing, but there are a number of packages I have to patch and update myself on Arch where on every other distribution there is a set of commonly used patches the developers just expect you to want. This is especially true of legacy applications like mutt.

So far, the switch has been OK, but far from painless. There are numerous little details that you take for granted when you’re running Arch, like the simplicity of the package manager. On Arch, your package management configuration goes in /etc/pacman.conf. The lines I am concerned with look like the following:

#[testing]
#SigLevel = PackageRequired
#Include = /etc/pacman.d/mirrorlist

[core]
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

[extra]
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

Breaking this down, # means a commented line, and the [core], etc. headings represent individual repositories. The order that the repositories are listed signifies their precedence. The Include = line points to the file with the list of mirrors for the repo. If you want to ignore a certain package from updates, there is an IgnorePkg= line that you change, to signify that you want to ignore it.

This format is easy to understand. Obvious, even. The reason I am detailing this is to contrast it to the Debian package management system. Debian’s package management configuration lives in /etc/apt. First there is sources.list, which describes sources from which you are getting packages. Mine looks like this:

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

deb http://ftp.debian.org/debian/ jessie-updates main contrib non-free
deb-src http://ftp.debian.org/debian/ jessie-updates main contrib non-free

deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free

deb http://cdn.debian.net/debian unstable main
deb http://cdn.debian.net/debian experimental main

The Debian Wiki describes this file, but I will summarize it here:

deb or deb-src describes whether you are getting binaries or source packages from the archive.
Then comes the URL.
Then you have the distribution. This can either be the release codename (e.g. squeeze, wheezy) or the release class—stable, testing, etc. My first point of confusion came here. I wanted to use Jessie, the current testing distribution—but how does testing/updates differ from jessie/updates? Are there updates for one, but not the other? Why can (or can I?) use both jessie/updates and jessie-updates, as seen in my config file?
Then come components. These are like sub-branches of an archive for a particular release. In this sense, they are akin to Arch’s repositories, if only one of them existed. I think if I hadn’t been coming from a rolling-release distribution, this might have made more intuitive sense to me. But personally, I just want to be able to specify all packages from Testing’s main, contrib, and non-free components, with the added ability to cherry-pick packages like iceweasel (Debian’s rebranding of Firefox) from unstable. Instead, I have to muddle with /updates distributions in addition to the main ones.

As it turns out, /updates isn’t necessary for [testing] users, but you are supposed to keep release-codename/updates around in case you wish to roll over to the codename release once it goes live. This makes sense, but it was confusing at first.

Then there is apt.conf.d, containing configuration settings for Debian packages, with examples like the following:

Acquire::cdrom {
  mount "/media/cdrom";
};
Dir::Media::MountPath "/media/cdrom";

APT::Authentication::TrustCDROM "true";

Upside: all of your package configuration is in one directory. The configuration settings are more intricate and powerful than on Arch. Downside: what is this configuration format? Based on the manual page, it is nothing I could understand with one quick grasp at its settings, though understanding will no doubt come with time.

Don’t even get me started on Apt preferences. That file is so complicated that not even the wiki authors seem to understand it. From man 5 apt_preferences:

Preferences are a strong power in the hands of a system administrator but they can become also their biggest nightmare if used without care! APT will not question the preferences, so wrong settings can lead to uninstallable packages or wrong decisions while upgrading packages. Even more problems will arise if multiple distribution releases are mixed without a good understanding of the following paragraphs. Packages included in a specific release aren’t tested in (and therefore don’t always work as expected in) older or newer releases, or together with other packages from different releases. You have been warned.

For package management, there’s dpkg for the base package manager (i.e. it can install .deb files), apt-get for downloading, installing, and removing packages, apt-query for querying package databases, apt-secure for digital signature verification of packages, and aptitude as a high-level wrapper around all of this. As to whether this is ideal or not, I have heard arguments both ways: some state that having all this separation complicates what should be a simple process, and others say that the Debian way of doing things is actually more unixy—do one thing, and do it well.

I’m not sure where I stand on that issue. Either way, Debian has given me some interesting new challenges, and there are layers upon layers of complexity to unveil before understanding how things are really working.