Ubuntu pretty much is the 'universe' repository for us

September 20, 2018

Recently, HL left a comment on my entry about Ubuntu bug reports being useless pointing out that part of the problem is Ubuntu's "Universe" repository. To quote HL:

The issue is of course that Universe is essentially a static snapshot of Debian unstable at the time of the relevant Ubuntu release. Some updates do happen, generally if someone contributes them, but Ubuntu does not consider the huge set of packages that only exist in Universe to actually be supported. [...] (In many cases it'd be best to just steer clear of Universe entirely, but most users have no idea about this distinction.)

In my book, Universe is one of Ubuntu's big weaknesses, and it goes way beyond bug reports.

At one level I can't argue with this. I don't think that Ubuntu does much bug fixing even for packages in "Main" (our experience has not been positive), but a package being in "Universe" basically guarantees that bugs are going to be there for the lifetime of the LTS release.

(It turns out that I looked into some factors here for Ubuntu and Debian a while back, in my entry on how much support you get from distributions.)

At another level, "Universe" is a large part of the reason that we use Ubuntu. Around half of the packages installed on our user-facing Ubuntu 18.04 LTS machines come from "Universe", and looking at the list of those packages suggests that users would notice if they all disappeared (certainly I would, since both xterm and urxvt are in "Universe", and let's ignore that Amanda is also a "Universe" package). For us, the attraction of Ubuntu is that it has three things in combination: reasonably frequent releases so that the most recent release is never too far behind, the five year nominal support period for any specific LTS release, and the large package selection. As far as I know, no other major Linux distribution has all of them.

(CentOS has more of them than it used to, since EPEL is fairly robust, but it misses out on release frequency.)

If we take "Universe" out of Ubuntu, as mentioned we lose about half of the packages that we install. What remains is not useless (and it includes more packages than I expected), but I don't think it would really meet our needs. If we had to drop "Universe", I suspect that we would wind up with a mix of Debian, for user-facing machines that we update every two years anyway, and CentOS, for machines that we can mostly freeze and live with old packages.

(Like Ubuntu, Debian has different sections of their package repository, but I believe they are much more likely to actually update "contrib" packages than Ubuntu is to update "Universe". If nothing else, there are more steps involved in Ubuntu than in Debian; you need a Debian update and then for someone to push it through the Ubuntu processes as well.)

PS: I'm only mildly interested in hearing if there's a real alternative to Ubuntu that meets all three of our criteria and improves on Ubuntu's support record and so on, because even if there is we might well not switch over to it. It's not that we love Ubuntu, but it mostly works okay and we already know how to make it do what we need (and have various pieces of tooling built for it and so on). It's our default Linux and Unix.

Sidebar: How I looked at the package split on our machines

First we generate a list of packages in each section:

cd /var/lib/apt/lists
cat *_main_*Packages | grep '^Package: ' | field 2 | sort -u >/tmp/main-pkgs
cat *_universe_*Packages | grep '^Package: ' | field 2 | sort -u >/tmp/univ-pkgs
cat *_multiverse_*Packages | grep '^Package: ' | field 2 | sort -u >/tmp/multi-pkgs

(field is one of my little utility scripts; you can find it here. Several years ago I evidently thought that you'd need to explicitly download some package index files, but it turns out that apt already has copies stashed away.)

Now we need a list of local packages:

dpkg --get-selections | field 1 | sed 's/:.*//' | sort -u >/tmp/inst-pkgs

The sed transforms package names like 'gcc-8-base:amd64' into plain 'gcc-8-base'. For my crude purposes, it's okay to crush multiple architectures together this way.

Then you can use comm to count up how more or less how many packages come from, eg, "Main":

comm -12 /tmp/inst-pkgs /tmp/main-pkgs | wc -l

This will have a lot of library packages, so you may want to crudely exclude them with 'grep -v "^lib"' or the like.

We turn out to have a few packages installed from "Multiverse", somewhat to my surprise. I think I knew that rar was non-free, but the OCaml documentation is a little bit of a surprise.

Comments on this page:

By Opk at 2018-09-20 06:17:27:

I'm not sure that EPEL is really any better. I get the impression that it depends on the package and who maintains it. And, when a new RHEL release comes out such as for 6 or 7, EPEL starts out fairly empty. We ended up having to grab .spec files intended for Fedora and build lots of things ourselves. I assume universe at least starts out fairly full when a new LTS is released.

Written on 20 September 2018.
« The Extended Validation TLS certificate endgame is here (to my surprise)
Why I mostly don't use ed(1) for non-interactive edits in scripts »

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

Last modified: Thu Sep 20 00:43:39 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.