Things that affect how much support you get from a Linux distribution

January 27, 2014

Recently commentators have noted (here and here) that you may get less support than you expect from distributions like Debian and Ubuntu because both split packages into multiple sections and may apply different support policies to different sections. In my view, there are several factors that affect how much support you get in practice in this situation.

The obvious first factor is what the official support policies are for the different sections of the package repository. This can be a little bit hard to find out, but Debian's is here and Ubuntu's seems to be more or less here (assuming that Ubuntu LTS doesn't change the support picture, just lengthens it). Both fully support only their main section and seem to leave support for other sections up to the community.

(Debian is explicit about this; Ubuntu seems to imply it.)

The next question is what packages are in what section. In Debian and Ubuntu there are two ways to determine this. First, you can use command line queries such as 'apt-cache policy <package>' or 'apt-cache madison <package>'. It's a little bit tedious to do this for a lot of packages so if you want to do this en masse you're probably better off fetching the Packages file for eg Ubuntu 12.04 64-bit and processing it directly. This will let you see the full list of what's in the fully-supported Ubuntu main section; you can then correlate it against the packages that you care about.

Finally, what really matters is what happens in practice. A large part of this is whether the normal community maintainers of packages that turn out to have security issues step up to fix them and the security team then pushes out security updates. Beyond that, we might see people stepping in to push security fixes into packages that they don't normally maintain (including people who normally maintain core packages or perhaps even the security team) for various reasons. This is something that can only be assessed as it happens or on a historical basis, ie you go back to look at what security releases got made for non-core packages.

(A thorough assessment would look both at whether non-core packages got security updates and whether known security issues in non-core packages weren't fixed. For that matter you should look to see if fully supported packages got prompt security updates or if some things took a while or dropped through the cracks.)

I don't have any particular answers here, since generating them for even our own systems would take more work than I care to put in right now. I did take an informal look through what Ubuntu packages are in what section and almost everything I care significantly about is in main, which Ubuntu theoretically fully supports.

(I looked at things like OpenSSH, Apache, Dovecot, Exim, and Samba.)

Sidebar: Another place to look

Ubuntu's security repository segments things by section, which means that you can get a list of package security updates for universe, multiverse, and so on. Checking shows me that Ubuntu has released at least some 12.04 security updates for packages outside of main. I have no idea how comprehensive these updates are (ie, how many packages outside of main have security issues but no updates).

(See eg here for 12.04.)

Debian probably does the same thing but I haven't checked.

Comments on this page:

By Ben Hutchings at 2014-01-27 06:21:35:

Bear in mind that Debian's main contains the entirety of the official Debian system - everything that's free software and doesn't have non-free dependencies - whereas Ubuntu's main is what they consider the core OS. There is a Debian core that is better-supported than the rest; it's just not as clearly defined as in Ubuntu.

Each package contains its section name, which might be overridden in the 'FTP archive' but at least in Debian the major section (main, contrib, non-free) won't. So you can get that with just the dpkg tools:

xargs dpkg-query -W -f '${Package} ${Section}\n' | sed 's@ \(contrib\|non-free\)/.*@ \1@; t; s@ \(..*\)@ main@'

-- BenHutchings

Written on 27 January 2014.
« Why writing sysadmin tools in Go is getting attractive
Building software packages yourself is generally a waste (why package selection matters) »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jan 27 02:31:18 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.