discord_bridge[asciilifeform]: (gregorynyssa) http://logs.nosuchlabs.com/log/pest/2025-01-26#1034703 << The phenomenon which you and I dislike might be referred to as "sparsive packaging." The term "sparsive" means "scattering."
dulapbot: Logged on 2025-01-26 09:56:53 hapax: my $PATHs are sometimes miles long though
discord_bridge[asciilifeform]: (gregorynyssa) Basically when you install a package (whether or not you compiled it yourself) the one-or-more executable files are placed in one location, and then the various supporting files are placed in various locations.
discord_bridge[asciilifeform]: (gregorynyssa) There are at least three reasons (based on my research) that sparsive packaging is the overwhelming practice within the ecosystem of Linux.
discord_bridge[asciilifeform]: (gregorynyssa) One of them is the curse of hardcoded paths. Many if not most executables expect certain files to be in certain places. In the more fortunate instances, these locations can be overriden with a command-line option, but even then, I would argue that paths should not be hardcoded.
discord_bridge[asciilifeform]: (gregorynyssa) An executable should be viewed as a transformer between two states of the filesystem. All paths which the executable deals with should be chosen at invocation because they represent the parameters of the transformation.
discord_bridge[asciilifeform]: (gregorynyssa) Even under Plan 9 this rule should not be relaxed. Rather, the use of parametric paths and per-process namespaces would complement each other.
discord_bridge[asciilifeform]: (gregorynyssa) It may be tedious to specify every parametric path for every invocation, but I would contend that it is the shell's reponsibility to relieve that burden (having shell-functions, shell-scripts, and the "alias" feature already goes a long way, but of course the shell might do even better).
hapax: http://logs.nosuchlabs.com/log/pest/2025-01-27#1034707 <<< "sek00rity first, not a single customer uses the old php!!1" still holds when there's no customers left
dulapbot: Logged on 2025-01-27 21:24:25 asciilifeform: subscribed since 2007!!! and nao loox like they don't particularly need customers?
hapax: don't know a single thing about php, unfortunately
hapax: http://logs.nosuchlabs.com/log/pest/2025-01-29#1034717 <<< funnily enough, the gnu autohell and the gnu "coding standards" actually alleviate the problem to some extent
dulapbot: Logged on 2025-01-29 01:30:11 discord_bridge[asciilifeform]: (gregorynyssa) One of them is the curse of hardcoded paths. Many if not most executables expect certain files to be in certain places. In the more fortunate instances, these locations can be overriden with a command-line option, but even then, I would argue that paths should not be hardcoded.
hapax: i was pleasently surprised when i realized most autoconfigurable packages (probably all with the "gnu" sticker slapped on top) can be completely configured during build when it comes to paths
hapax: (the configure scripts don't even need bash! any posix-compatible sh(1) works)
hapax: even monstrosities such as gcc have ways to play around (cf. --sysroot)
hapax: some packages cannot be moved around aftewards, but i usually just leave them where they are
hapax: still, even linux takes a command line argument for pid 1 (and the path can be complied in during build), there's usually some degree of freedom already in most places
hapax: people just take the PATH=/bin:/usr/bin for granted, package manager's gonna deal with that anyway
hapax: a problem unknown in the ms world (just doubleclick the .lnk on your desktop!)