When I was a beginner I was surprised (on university machines and clusters) that I can't install packages for myself but if I download the source, I can compile and use almost anything by putting it in my home dir. I still don't quite get why we have to do this dance and can't just install from apt into home, but whatever (downloading the .deb file and unpacking it as an archive is also an option though, but still quite some manual effort.)
A great tool to manage these home-based installations is GNU Stow. In fact I've written scripts that just take the tarball, compile it with the typical workflow (autotools or cmake), setting prefix and DESTDIR as needed and then use Stow to put it in place. Then if I want to "uninstall" something, I use `stow --delete`. Works well enough for most of the use cases, like installing a newer GCC or Cmake than available on a cluster etc.
That's actually how the nix package manager works, normal users can 'install', or even build, packages. It works because the installation does not really have any side effects beyond using some resources (disk space, network, CPU), which as you point out you could anyway use as a normal user.
Installing to /usr/local is not only simple and convenient—it's also what most build scripts do by default unless you specify otherwise.
For a lot of tools, I find that writing a port can be almost as little work and installing it manually. With the added bonus that the package manager will then track its dependencies and that I can share the port with other users of the distro.
Alpine makes this particularly easy thanks to the simplicity behind its APKBUILD files. BSDs usually have relatively simple recipe format too (although not as simple as APKBUILD or PKGBUILD tbh).
For starters, it’s not a UNIX thing. It’s really more a Linux thing. Some Unixes have also adopted it but not enough for someone to argue that someone “should” be using it in reply to an article about Unix more generally.
Secondly, XDG stems from managing desktop applications. Granted there’s no reason it can’t nor shouldn’t be used for CLI tools too. But equally there isn’t any reason why someone needs to use it. And on headless platforms, it makes zero sense to enforce XDG over any other Unix standard.
Lastly, XDG is surprising complicated. Your example of symlinks et al demonstrates just how much additional work you’re doing just to follow XDG here. If you CLI tool doesn’t spew dozens of config files in $HOME then your recommendation isn’t any better than the one in the article.
I really want to like XDG but like many things that originated from Linux, it’s far from an elegant solution to a simple problem and barely supported outside of Linux too. So I can’t blame anyone for deciding not to bother with it for their own personal software on their personal systems.
There used to be a "checkinstall" tool, so you'd ./configure, make, and instead of "make install" use "checkinstall" - this would make some fakeroot magic, install the package and create a deb package for it, that could be apt-get removed later.
And iirc, automake uses /usr/local by default (if you didn't specify the --prefix).
Yep, I'm in this camp. In particular, since the bin/lib dichotomy doesn't work well for everything[1], I'll put things free-form in /opt as needed, and then symlink executable entry points at /usr/local/bin. [2] This is also more or less what Pipx global installs (available since version 1.5.0) do (https://pipx.pypa.io/stable/installation/#-global-argument).
[1] e.g. if you want to install Python applications in isolated virtual environments, the venv has its own bin/ and lib/ internally - you wouldn't want to flatten that structure and have all those applications share top-level /usr/local/bin and /usr/local/lib, because that would involve manually destroying the venv structure and also defeating the entire purpose of them.
[2] although this is not completely smooth if, like me, you want to compile multiple versions of Python from source and then make venvs based off of them - see https://github.com/python/cpython/issues/106045 .
The only time my home directory gets cleaned up (it is littered with random binaries) is when I get a new machine... It feels very wrong, but also quite cathartic at the same time!
I install them in ~/p/... and have a script that walks any directory under ~/p/ and if it has a 'bin' subdirectory, it adds it to the path, otherwise it adds the directory itself to the path. (it also wipes existing ~/p/ paths before the search, enabling it to also act as a path updater)
So after that it's `./configure --prefix=$HOME/p/`, `make install` and `build-personal-path`
I can't speak to their use case but why not use Gentoo? Portage solves a lot of these problems with slotting or by letting you roll your own ebuilds with a local repo. It seems cleaner and less effort, unless you need/like the Ubuntu userland.
Readit News
A great tool to manage these home-based installations is GNU Stow. In fact I've written scripts that just take the tarball, compile it with the typical workflow (autotools or cmake), setting prefix and DESTDIR as needed and then use Stow to put it in place. Then if I want to "uninstall" something, I use `stow --delete`. Works well enough for most of the use cases, like installing a newer GCC or Cmake than available on a cluster etc.
`/usr/local` for system level, non-managed packages
`~/.local` for user level, non-managed packages
`/opt` for system level "add-on" packages. Typically proprietary upstreams. Zoom, Discord, the proprietary builds of Chrome or VSC, etc.
For a lot of tools, I find that writing a port can be almost as little work and installing it manually. With the added bonus that the package manager will then track its dependencies and that I can share the port with other users of the distro.
Alpine makes this particularly easy thanks to the simplicity behind its APKBUILD files. BSDs usually have relatively simple recipe format too (although not as simple as APKBUILD or PKGBUILD tbh).
For personal installations you should use $XDG_DATA_HOME: https://specifications.freedesktop.org/basedir-spec/latest/#... and then create symlinks to binaries in $HOME/.local/bin.
For starters, it’s not a UNIX thing. It’s really more a Linux thing. Some Unixes have also adopted it but not enough for someone to argue that someone “should” be using it in reply to an article about Unix more generally.
Secondly, XDG stems from managing desktop applications. Granted there’s no reason it can’t nor shouldn’t be used for CLI tools too. But equally there isn’t any reason why someone needs to use it. And on headless platforms, it makes zero sense to enforce XDG over any other Unix standard.
Lastly, XDG is surprising complicated. Your example of symlinks et al demonstrates just how much additional work you’re doing just to follow XDG here. If you CLI tool doesn’t spew dozens of config files in $HOME then your recommendation isn’t any better than the one in the article.
I really want to like XDG but like many things that originated from Linux, it’s far from an elegant solution to a simple problem and barely supported outside of Linux too. So I can’t blame anyone for deciding not to bother with it for their own personal software on their personal systems.
Deleted Comment
There used to be a "checkinstall" tool, so you'd ./configure, make, and instead of "make install" use "checkinstall" - this would make some fakeroot magic, install the package and create a deb package for it, that could be apt-get removed later.
And iirc, automake uses /usr/local by default (if you didn't specify the --prefix).
Amazing! :D
* Linux: "/usr/local" or "/opt/local" depending on distro
* NetBSD: "/usr/local", NetBSD packages go into "/usr/pkg". I wish all other systems adopted pkgsrc :(
* OpenBSD: "/opt/local", OpenBSD packages go into /usr/local
If on a system I do not "own", like AIX at work or SDF, I use $HOME/local
[1] e.g. if you want to install Python applications in isolated virtual environments, the venv has its own bin/ and lib/ internally - you wouldn't want to flatten that structure and have all those applications share top-level /usr/local/bin and /usr/local/lib, because that would involve manually destroying the venv structure and also defeating the entire purpose of them.
[2] although this is not completely smooth if, like me, you want to compile multiple versions of Python from source and then make venvs based off of them - see https://github.com/python/cpython/issues/106045 .
Dead Comment
So after that it's `./configure --prefix=$HOME/p/`, `make install` and `build-personal-path`