The joy of Open Source®©™ software
The r*dh*t package management system (egotistically self-named) uses a spiffy (if your definition of spiffy includes such features as unreliable kernel locking and a collection of source code that has been known to drive people to clinical insanity) little program called rpm to do the dirty work of installing packages, updating packages, doing queries on packages, and verifying that packages are properly installed. (It also, unintuitively, calls a background daemon to rebuild the internal databases, so if you start a database rebuild, realize that this was a mistake, then kill the process you're actually killing the user interface while the rebuilder continues unstoppably along in the background. What a lovely feature this is, he said, cursing under his breath.)
One thing that's almost useful, but not quite, is the verify mode you can put rpm into. There are many settings you can feed to the verifier to tell the code to check or not check links, md5 checksums, phase of the moon, and whether the rms password is blank or not, but one setting that is not provided is a way to tell the verifier to not check config files to see if they've changed (config files, since they're, um, config files, tend to change on a site-by-site basis.) At work, we want to use the verifier to check to see if all the packages on our distribution have installed happily, but since we actually modify config files, many many many packages just won't verify because, oh the horror, the config files are different.
No problem, I'll just patch rpm with a --less-stupid flag to tell the verifier to STFU about config files. Easy, no?
Um, actually, no. And I'm not sure why. But, first some history.
In the old days (version 7), there wasn't any standardised way to handle command line arguments on Unix, so everyone just did their own command line mangling inside of their programs. This was all fine and good, but it wasn't particularly maintainable and it allowed some fairly spectacularly nonstandard ways of doing options. To help solve this feature, some brilliant programmer (at AT&T?) wrote the getopt() function, which nicely encapsulated the whole business of picking apart arguments so you didn't have to deal with the joy of doing it yourself. It had a few oddities, but if you used getopt() you could be pretty confident that your program would process command line options pretty much the same way that everybody else would.
Some people think that the traditional Unix commandline arrangement has some flaws in it. In particular, there is a small but powerful group that loooooves VMS-style command options, and constantly regrets that it's "ls -l" instead of "dir /LONG". So they wrote their own version of getopt() that handled long arguments, and boy, was it clunky. So some other people wrote their own versions of long argument getopt, and eventually it became a party with at least a dozen or so completely incompatible getopt() replacements (I'm not completely innocent here), each of which has their own collection of special features to fight with.
A case in point is the one that rpm uses. You'd think that all you need to do is to stuff a new option into the getopt table (this one is called popt(), and it's an invented-at-r*dh*t "solution" to the NIH problem), set up a stanza in the big switch for options processing, and bob's your uncle. Um, no. Instead of just setting the options up in the argument processing code, you need to play hunt the trucks all over the guts of a pile of code that's the architectural equivalent of a 40 car pileup on the interstate.
Maybe it's time to become a farmer, or a sewage management technician.
Comments
Comments are closed
Under your breath or not, I’ll bet the daem*n heard you.