Wandering Thoughts archives

One reason why the Debian package format is not my favorite

In their wisdom, the people who created the Debian package format decided to allow packages to ask the person installing them questions. By including this feature, they insured that Debian packages do quiz the people installing them about various things.

The problem with this is that questions are landmines. Every time you ask one, you are gambling that the person knows enough about the issue to give you an informed answer. When they do not, at best they just pick the default answer (fortunately Debian seems to mostly insist that package questions have default answers) and you have just made them nervous.

Worse, every question that a Debian package asks is a decision the people building the package have pushed off to the people installing the package. Let's rephrase that: every question is a decision that the people who know the package best have deferred into the hands of people who are just installing it, perhaps merely because their users asked for it or they thought it sounded interesting.

The great advantage of package formats that do not allow install-time questions is that they force the people building packages to actually make decisions, not duck the issues.

(This entry is brought to you by the Ubuntu ilisp package, which felt it was burningly important to ask me whether it should use FSF compliant keybindings or some other ones.)

Getting source RPMs with yumdownloader (part 2)

To follow up the first installment, it turns out that enabling the source repositories has a side effect that I didn't think about at the time: it no longer looks in the default repositories.

(This is a general thing in yumdownloader: any time you specify a repository explicitly, it disables all the default ones. This makes me grumpy. While you can argue that this makes a sort of sense, it is not how yum itself behaves when you enable repositories, and yumdownloader uses the exact same command line switch that yum does, so people are going to expect it to behave the same.)

This matters because there are binary RPMs that are built from source RPMs with different names; the obvious case is most of the -devel RPMs, but there are a number of others that are less obvious (this is why the extra mapping step mentioned in the first installment exists). Unfortunately yumdownloader consults the normal binary RPM repositories to find this information, and without them gets nowhere.

(At least you get an error message.)

Since this means that you now really want to give yumdownloader at least seven switches (six of them with arguments) to download source RPMs, I now have a shell script I call yumsource:

; cat yumsource
#!/bin/sh
yumdownloader --source \
    -e core-source -e core \
    -e extras-source -e extras \
    -e updates-source -e updates \
    "$@"

(Add extra repositories to taste. I admit my real script has the livna repository too.)

Getting source RPMs with yumdownloader

In theory, the yumdownloader program that is part of the yum-utils package will download the source RPMs if you want it to. In practice I spent a long time having it not work on my Fedora Core 6 machines, until I read yet another bland bit of advice telling me to use it and decided to figure out just what was going on.

(The problem was quite frustrating, because yumdownloader never complained; it just silently did nothing.)

It turns out that the trick is that you need to specifically enable the source repositories; these are not enabled by default. At least in Fedora Core 6, the names of these repositories are core-source, updates-source, and extras-source (for the core, core updates, and Fedora Extras respectively). Unless you already know where an RPM package comes from, you might as well enable all three.

And I have to praise the Fedora Wiki's guide on how to rebuild kernel RPMs. Not only is it a useful guide to building kernel RPMs, but without it I wouldn't have been pushed into figuring out what was up with yumdownloader.

(I do suggest using quilt to put together patches instead of their more brute-force approach.)

Sidebar: why yumdownloader is silent when this happens

Yumdownloader's silence in this case is probably a bug, and it's sort of an interesting one. The normal process complains if a command line argument cannot be mapped into one or more RPMs. However, when you ask for source RPMs there is an additional step to map the RPMs found for each command line argument into their source RPM, and this mapping code doesn't check to see if it wound up with any source RPMs.

(I suspect that the yumdownloader developers have the source RPM repositories enabled by default.)

RPM's multi-architecture file ownership problem

An increasing number of Red Hat/Fedora machines are dual architecture: they run both 64-bit and 32-bit x86 programs, and thus need to have shared libraries and RPMs and so on for both of them. This can expose some interesting issues when installing and upgrading RPMs; one of them is the dual architecture file ownership problem.

There are a lot of RPMs that install both architecture-dependent files like binaries and shared libraries and architecture-independent files like header files and manpages. The architecture dependent files already go into different places, so you can easily install both the x86 and x86_64 versions at the same time, but the same is not true of architecture-independent files; there is only one /usr/share/man.

The RPM people decided that the easiest solution to this problem was to allow more than one RPM to supply the same file, provided that all versions of the file were exactly the same. That way, if libfoo.x86 and libfoo.x86_64 provide exactly the same manpages, they can coexist, and anyways there's no reason for the manpages to be different just because of the architecture you built the RPM for; such differences are effectively a bug.

However, this has a side effect: you usually have to upgrade the RPMs for both architectures at the same time, because there is no guarantee that libfoo-1.1.x86 will have the same manpages as libfoo-1.2.x86_64. If you can't do this (perhaps all the necessary RPMs aren't in the updates repository yet), you get weird errors about how files from libfoo-1.2 conflict with files from libfoo-1.1 (unhelpfully, yum doesn't tell you the architectures of the RPMs involved).

Sometimes you can deal with this by removing the RPM for the unavailable library, but sometimes you really do need the x86 version of libfoo and you're stuck until libfoo-1.2.x86 gets built and pushed out.

In fact, if you stick to well-run repositories, file conflict errors on a dual architecture machine are almost always the sign of an architecture clash. Well run repositories just don't normally allow RPMs with clashing files, so the only way to get a file clash is because yum is somehow pulling in an RPM from the wrong architecture. (Unfortunately, hunting down where and why can be challenging.)