Sometimes you wonder why a vendor might include a tool which seems so useful but ends up being more of a waste of your time than anything else.

So it was, today, when I found that I needed to install a complete development environment on a Red Hat Enterprise Linux 3 Workstation system. “Ah,” I said to myself, “this should be quite simple! After all, Red Hat includes this wonderful utility that lets you select and install software packages after the initial install.”

Hah.

The utility in question is redhat-config-packages via the command line (I have no recollection of what the GUI menu item for it is.) It’s a GUI application for the X windowing system, so I fired it up, pointed back at my Linux workstation’s X display, and set to work. I scrolled down the lists of package groups, exactly as they are presented to you during the system installation, and selected the “Development” and “Kernel Development” groups. I then clicked on the “Update” button, and was presented with a wonderful error dialog, alerting me to the fact that the application couldn’t find a package that it needed.

For those that don’t know, when you purchase a license for RHEL, you get a year’s worth subscription to Red Hat Network, which gives you the wonderful ability to install updates and new packages via the ‘Net. At least in my mind, then, it wasn’t a great leap to assume that the “install new software” tool would utilize this facility. Well, not only is that not the case, but if you’ve applied any updates at all to your system after the initial install, redhat-config-packages simply doesn’t know how to deal with the resulting dependancy issues, apparently because it knows nothing about the up2date tools.

In fact, this was an issue right at the initial release of RHEL 3, and at least one bug was filed with Red Hat over this issue over a year ago. Search for “krb5-libs unlocatable” on Google and you’ll come up with a number of people complaining about this very problem.

Why bother including a utility that is likely going to fail under expected use profiles? Back before it was so easy to update a system, sure, including a utility that based all it’s package installation and dependency tracking on the CD’s used to install the OS made sense. However, when you expect your end-users to update their systems as you release fixes and patches, shouldn’t your users expect your tools to take that into account? And why let the bug linger for over a year without so much as a comment?

Really, how hard would it be for redhat-config-packages to check with up2date to see if what it needs can be fetched via Red Hat Network? Why should I have to figure out all the individual packages on my own, just because the tool that would otherwise do it for me doesn’t know how to handle anything other than what was on the install CDs?

This was quite maddening.

This entry was posted on Tuesday, April 12th, 2005 at 3:04 pm and is filed under General Geekery, Linux, Software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.