Alex Hudson

Thoughts on Technology, Product, & Strategy

Is package management failing Fedora users?

(For those looking for an rpm rant, sorry, this isn’t it….!)

Currently there’s a ticket in front of FESCo asking whether or not alternative dependency solvers should be allowed in Fedora’s default install. For those who don’t know, the dependency solver is the algorithm which picks the set of packages to install/remove when a user requests something. So, for example, if the user asks for Firefox to be installed, the “depsolver” is the thing which figures out which other packages Firefox needs in order to work. On occasion, there is more than one possible solution – an obvious example often being language packs; applications usually need at least one language installed, but they don’t care which.

I don’t particularly have much skin in this particular game; but what I would note is that I find it particularly bizarre that this task is delegated to an algorithm. What we’re saying, basically, is that the configuration of a given installation is chosen by a bit of software. So long as the various package requirements – which could be library versions, files, or something entirely synthetic – are all met, the configuration is “valid”. Of course, that doesn’t necessarily mean it works – it may be totally untested by anyone else, and things get particularly grizzly if you’re doing something “fun”. Such fun includes:

  • deploying “multi-arch” packages. Maybe you want a 32-bit browser plugin on your 64-bit PC, for example;
  • installing third-party packages. Maybe it’s RPM Fusion, maybe it’s an ISV – but where-ever it’s from, it’s another set of variables the depsolvers looks at;
  • installing your own packages. See above.

The package management system doesn’t have a concept of “OS” and “other stuff”. Being able to override such a concept would be a feature; not having it is not a feature however.

Now, fans of package management frequently tout the many benefits, and they are indeed multiple. It makes it easy to install new software and be reasonably sure it works (it may need a lot of configuration, though). Splitting stuff up into a thousand different bits makes security updates more straightforward (at least, in theory – see later). But in general, to conflate all these issues is a bit of a mistake: there are other forms of installation system which provide these benefits as well.

So, what’s wrong with this? We’ve already seen that the choice of depsolver can potentially make or break the system, or at least lead to configurations which were not intended by the packagers, but to some extent that could be solved by tightening the specification/package dependencies, so that the “right choice” is obvious and algorithm-independent. But, there are other issues.

It’s difficult to estimate the number of Fedora users, but the statistics wiki page makes a reasonable effort. And looking at that, we can see that about 28 million installs of almost 34 million (that are connecting for software updates) are currently using unsupported releases of Fedora. That’s over 80% of installs using a release which is no longer supported.

This of course has security implications, because these users are no longer getting security updates. No matter how fancy the package management, these people are all on their own. And unfortunately, the package management tools are not much use here: effectively, unless you use the installer in one of its guises, the procedure is difficult and potentially error prone.

You’re also out of luck with third-party repos: the package manager doesn’t insulate them from each other, so mixing is frowned upon. It may work, it may not. You may be able to upgrade, you may not. It may alter core functionality like your video driver, and you might be able to downgrade if it failed, but let’s hope it didn’t manually fiddle with things.

In the meantime, we’re also failing to deal adequately with many types of software. The Firefox update process causes enough problems with the current setup; Google’s Chromium on the other hand appears to be almost entirely impervious to being packaged in a Fedora-acceptable way. Web applications also don’t work well; Javascript libraries don’t fit well/at all into the concept of libraries a la rpm, so there’s loads of duplication.

There’s probably an awful lot more that can be written on this topic, and of course package management right now, for the most part, works pretty well. But I worry that it’s a concept which has pretty much had its day.


Speculation on Google’s “Dart”


“Dart” out in the open – what’s it all about?


  1. Re: Chromium, the actual Chromium code is the problem, there isn’t any possible packaging infrastructure that would make it Fedora acceptable. I’m able to package it into RPM format just fine. The key Chromium problems are:

    * upstream moving incredibly quickly, with no regard for ABI/API
    * upstream bundling everything they come across, then forking the items that they bundle

  2. Hey Alex,

    Interesting idea about package management having had its day. There are certainly plenty of modern applications that don’t easily fit into the package management paradigm, particularly web and javascript apps, as you’ve said.

    What sort of alternatives would you suggest?

    Also, the biggest reason I like unbundled libraries / package management is the security aspect. How would your alternatives address this?

  3. Alex

    Tom, I disagree that the chromium code is “the problem” – the problem is the incompatibility between the style of development of chromium, and the Fedora processes. One can argue the merits of both sides of that, but I’m not making a technical comment about RPM particularly.

    So, for example, you cite the ABI/API churn and bundling as two critical problems. But they’re only problems because of the way package management works in Fedora. We look down on bundling because it bloats memory and makes it more difficult to issue security fixes. In the grand scheme of things, though, another few meg of library data makes very little difference to most people (the runtime working set of such software is much greater than the code they use), and the security fixes argument is a little bit trite when 80% of users aren’t receiving them.

    As you say, it would be perfectly possible to distribute an RPM of chromium – it’s just that policy-wise, Fedora chooses not to. This isn’t a technical issue, but this is precisely the issue I’m pointing out!

  4. Alex

    Hi anon.

    I didn’t propose any alternatives, you’re right – to be honest, I’m not really sure what the alternative ought to look like. I think we need to start from first principles, though, and work from the basis of what best meets the needs of the users.

    I think the security aspect is interesting, because it’s the most obvious “the perfect is the enemy of the good” problem that Fedora has with package management. Yes, unbundled libraries make it really easy to issue security updates. However, 80% of the users (we can argue the actual figures, hopefully we can agree it’s probably a majority) aren’t receiving security updates! So, if we really care about security, we should prefer to make the distribution as easily upgradable from release to release as possible – and if that’s at the cost of unbundled libraries, then as far as I’m concerned, so be it (however, I don’t think the two are incompatible).

Leave a Reply