Aversion to Versions

Dear KV,

Recently I have been trying to piece together a set of software packages that are supposedly intended to work together but seem very fragile. The main source of their fragility comes from how the developers “resolved” the dependencies between packages, libraries, and their own software. Their solution to making all the pieces work together was to encode the version of the library or package into the file system, as in, /opt/pkg-v2.87/lib/…. As you might imagine, this causes no end of trouble for us consuming this software when a library or package is upgraded. I have counted no fewer than 30 locations where this was done. You cannot tell me that this is the right way to handle this particular problem, but these people are paid professionals, and we paid for their software. What would KV do?

Aversion to Versions

Dear Aversion,

The problems of dependency analysis and resolution—as well as versioning—have been with us since the earliest days of the software library, and some of the solutions, such as SAT solvers for package systems, are clever and elegant and mostly work. Build dependencies are usually handled by systems such as automake and autoconf, which, so long as you never look inside them, are quite useful. If you look inside, you will not only see how the sausage is made so much as how the ingredients were processed and eventually spat back out as a makefile. All of which is to say that these problems are solved, and the solutions are often complex and tortuous, but we all admire those who undertake to solve them.

Then there are those who, either through ignorance or stupidity, decide just to take a stab in the dark and solve the problem in their own, inimitable style. It is definitely these types you are dealing with today. I guess you could file a bug against the software and see if someone fixes it. But given the quality of what they have already given you, I think that is a long shot.

Since you have been able to count the number of these sins committed in software (and you number them at 30), I am assuming you have some amount of the source code; perhaps it was even all delivered as source. One quick and very dirty solution is to use the inimitable sed (stream editor) program^a to update the version numbers as necessary. A manual page can be found here, but I am sure Stack Exchange or some other cheater site will give you code to “swap version numbers throughout my code” or some such thing. Just slap the code into a repo somewhere, find the right incantation of sed(1), sacrifice a live animal of your choice, and voilà, you will be able to update the versions to match the latest library. Purists will scream this is not the right way to solve the problem, and they are correct, but then purists have plenty of time to do the right thing, while the rest of us are trying to do the thing right.

Of course, the better way—and again you will need the source to do this—is to update the code to actually take a path argument or inquire after some sort of environment variable (MYLIBPATH) that can be used to point the software to the right place, no matter what version you want it to use. If you go this route, be sure to tell the developers you will send them the patch.

The higher-level point here is that one should never hardcode a version or a path inside the code itself. Code needs to be flexible so that it can be installed anywhere (the hardcoding of /usr/local is blatantly foolish and yet persists) and run anywhere so long as the necessary dependencies can be resolved, either at build time for statically compiled code or at runtime for interpreted code or code with dynamically linked libraries. There are, as KV has just pointed out, current, good ways to get this right, so it is a shame so many people continue to get it wrong.