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:

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:

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.