A package dependency failure in Fedora 15

June 14, 2011

I have a quite simple view of package dependency failures for packages in a distribution's official repositories: they shouldn't exist. More precisely, any package with unmet dependencies should be excluded from the repository. Letting such packages sit in your repository is an unhelpful lie, one that particularly irritates sysadmins, and in my opinion it makes you look just as amateurish or at least frustrating, as frustrating as those stores that list things as available only to turn out to be out of stock on them when you actually try to order.

(Ideally the repository would exclude all uninstallable packages, but there are twisty situations where checking that is complicated. But checking for unmet dependencies is relatively simple and straightforward.)

Today's offender is Fedora 15 and the gnome-applet-sshmenu package (I've grumped at Ubuntu for similar issues, so turnabout is fair play). As covered in Fedora bug #711555, this depends on a package capability (Ruby bindings for the Gnome panel) that is not available in Fedora 15 because of the upgrade to Gnome 3. This unmet dependency is trivial to find and determine. But it wasn't, and so you have an uninstallable package sitting in the Fedora 15 repository, tantalizing and annoying people.

Fedora should have detected this and at least rejected the binary package, well, excluded it from the repository, in just the same way that it would reject any other flawed binary package. (Rejecting the source package that it was built from and all of the binary packages that the package generates would attract the maintainer's attention, but might be too drastic.)

There are various side effects of this broken package sitting around in the repositories. The one that I ran into is that you can't do a yum upgrade from Fedora 14 if you have the package installed; if you try, you get various sorts of odd errors that take some work to sort out.

(Another yum upgrade failure appears to be due to the presence of libpanelappletmm, but that seems to be a different issue.)

In other news, it looks like I need to learn how to write Gnome panel applets in Python if I want to upgrade to Fedora 15 any time soon.

(The prospects for Ruby bindings for Gnome 3 appear low, and with no Ruby bindings, so much for the sshmenu applet that's an important part of my nice ssh environment for Gnome. Fortunately I can probably do a hack job replacement in Python without too much work, assuming that the Python bindings are sane.)

Sidebar: why detecting uninstallable packages is hard

Suppose you have a package A that depends on B and C, both of which exist and are installable separately. A simple dependency check will pass package A and say it's installable. Now, suppose that B and C conflict with each other somehow so that you can only have one of them installed at the same time. A is no longer installable, but to detect this you must detect that B and C clash. Obviously, the fully general version of this problem can have the conflict occurring down in the depths of a dependency chain instead of in direct dependencies.

(RPM makes the problem worse by increasing the number of ways that packages can clash; for example, they can try to install two different versions of the same file. So in an RPM based system it isn't sufficient to just check for explicitly declared conflicting packages.)

I'm sure that this is solvable, but it's nowhere near as easy and simple as detecting completely missing dependencies.

Written on 14 June 2011.
« An example of the evolution of a real network
The persistence of spammers, illustrated »

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

Last modified: Tue Jun 14 00:58:07 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.