💾 Archived View for thrig.me › blog › 2022 › 10 › 21 › software-depot.gmi captured on 2024-07-09 at 00:53:43. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-14)
-=-=-=-=-=-=-
A "software depot" is a term one may find used for collections of software installed and managed by some means; this could typically be the ports or package system that many operating systems now provide. A software depot could also be something more complicated (Nix, by way of nixos.org) or simpler, such as a bunch of shell scripts to install what you need; shell scripts can mutate into configuration management suites of various levels of complexity (judo, rset, Chef, Ansible, etc).
A software depot could also apply to libraries provided by a programming language (CPAN for Perl followed CTAN for Tex, among other imitators). These libraries could be managed with tools that ship with the language, or might also be built into the OS package system, or some other software depot. This can be as simple or complicated as you want it to be.
Specific applications may use something like a software depot, where the exact versions of various libraries are bundled together for service X running on port Y, as distinct from services P or Q possibly running on the same system, e.g. via Carton for Perl or similar for many other languages. A user might have their own software depot under their home directory, or if they are the sole (or sole dictator) of the system, they could instead use the OS package system for their custom software.
There may be a hierarchy; a user's home directory configuration or that of a service may need to modify or override commands provided by the OS or package system. Such modifications may be complicated in a package system where a simple ~/bin/foo wrapper script may suffice.
Consider the st terminal (from suckless). It is packaged on OpenBSD, so could be installed with the package system. However, one may wish to customize this software. This requires recompiling st, which creates a conflict with the operating system provided package. Solutions include:
Among other approaches. These have various benefits and drawbacks, some of which boil down to personal choice and whether you are managing the systems like pets or like cattle. Usually it is more like cattle as the number of systems increases, and the time to maintain them decreases. Some will try to automate the install of even a single system, others, less so. I recall two coworkers spending a great deal of time trying to fully automate a Wordpress install on an ancient version of RedHat Linux. Another put the private keys for a wildcard certificate into a shared git repository to better automate the installation of things that needed those certificates. Tradeoffs...
Note that a modified package will conflict with the original st package; if there are two users on a system who want different compiles of st then the single operating system package for st will not work, though a compromise might be made to install bin/st (the operating system package) and bin/st-for-bob, or maybe Bob's version gets installed to a custom bob/bin directory so that Bob can use st without having to change the name on certain systems. The complexity can be pushed in all sorts of directions. Two or more users in conflict is pretty much the same as two or more services in conflict, except that a web service may complain less than Bob does. With lots of users (or services) or with lots of conflicting requirements one might look to stow or Nix type solutions, though I've heard of Nix being too complicated for some to accept (via commentary on Hacker News), and have seen that configuration management may be too complicated for some to use, so there could be drawbacks if enough users of the system do not get onboard. If the one person who knows and uses Nix leaves, what then? Or what if it takes six months for new hires to get up to speed with the installation system? Again, tradeoffs.