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
Post a Comment