Skip to main content

Obsolete versions

Once upon a time, upgrading packages was just downloading and installing files. after a while, it also entailed compiling source code because my operating systems no longer received first-class support.

Descent Into Madness

after a while, upgrading a package also entailed upgrading the tools needed to make it and their dependencies. i felt like i had installed every (meta-)build system. on one of my MacBooks, Homebrew maintained two versions of Python and two versions of llvm.

as projects migrated from Autotools to CMake, library versions became inconsistent. these inconsistencies puzzled me, because the first test one should perform after adding support for another build system is determining if the result is the same. any differences should be eliminated/explained. in real life, most people didn't care because version requirements are rarely enforced. unfortunately, obsolete versions of macOS will not load an application if a library it needs doesn't satisfy its compatibility version requirement (see Siguza).

recently, a library upgrade broke two applications i use. Autotools builds version 9.6.0, whereas CMake builds version 0.6.8 while putting 1.3.6 in the library's path. ay, caramba!

unable to revert, i created a Python script that modifies a library's version. doing this was fairly easy, and necessary because ancient versions of macOS are not supported?

Return to Normalcy

though Homebrew is the de facto standard macOS package manager, this post explains why MacPorts is better if you use an obsolete version of macOS.

after removing Homebrew and the packages it installed, i reinstalled the packages with MacPorts. Python users should expect minor issues with pip (e.g. it installs mypy in a directory that is not on your PATH), but this library version issue seems historic.

Comments

Popular posts from this blog

Improper english

Before retirement ended my last spell of unemployment, i wondered if the timing of that dismissal was ideal. one month earlier or later might have been better? improving a server log was my last assignment. like many other companies, their senior management believed in their culture, technology, and tools. like other well-funded companies, they used Splunk and wanted to use JSON format. nobody reviewed the pull request that would have established a baseline for my work. their Splunk dashboard code was not versioned. Overcommunicating JSON can be ideal, and creating a data structure to discover if a log entry describes an error is easy and reasonably fast, but computers find strings very quickly. a faster algorithm uses less electricity; computer activity is human activity. ...

Cat's whiskers

Online forums are good sources of information and/or habitats for groupthink. Jean Valjean ignored the smell; so can you :-) forums are biased in various ways. for example, woodworkers' opinions about linseed oil are informed by wood finish products. in another forum, we might find a recommendation for finishing wood with linseed oil sold by an art supply store. sauce for the painter is sauce for the woodworker? Slippery when wet when i became interested in safety razors, forums were invaluable sources of information. they are still helpful, but i learned enough to continue on my own. at one point i bought cheap shaving soap thinking that it couldn't be as bad as forum contributors claimed. they were right, but the soap was/is still useful: it stays at th...