while kiss orphans | grep -qv $HOSTNAME; do
kiss remove `kiss orphans | grep -v $HOSTNAME | tr '\n' ' '`
done
sudo pacman -Rns $(pacman -Qqdtt)
Habitat (hab), nix, and others IIRC do SxS package mgmt.
Everything Should Be Made as Simple as Possible, But Not Simpler - possibly paraphrasing Einstein
Another elegant way, for a more civilized time, is to simply disallow dependencies. If none of your packages has any dependencies, then no dependency hell is ever possible. This is possible and easy with static executables (for binary packages), and by embedding the interpreter of packages written in scripting languages.
App::staticperl will build a static binary with the perl+C dependencies built in.
A lot of the time, it's better to use a plenv + Carton, mind, but if you want a single file for deployment, that's a solved problem in perl land too and has been for years.
On every distro uninstalling packages never really reverts the system to its previous state, always leaves some junk behind.
That's not true at all. See Nix package manager (and NixOS the distro).
$ realpath /etc/fstab
/nix/store/06k708q78zxw8922rrrc8mmp5gbin4am-etc-fstab
You can avoid such accidental state [1], since NixOS will happily boot from a filesystem with just /boot and /nix and reconstruct the rest upon system activation. But it is quite a bit of work, since you need to manually specify what state you want to preserve (e.g. SSH host key files). Also, it currently does not work nicely with some systemd units that barf out if you make /var/run entries symlinks.
For the moment I’m doing this on MacOS with the nix package manager. I’ll eventually move to NixOS. I tried to run NixOS in VirtualBox, but couldn’t get screen resizing to work despite using the official ISO which is supposed to have the appropriate extensions installed.
My current hurdle is exactly the topic of this thread: non-binary configs. For example, what am I supposed to do with .zprofile? I think I’m supposed to write a custom Nix derivation for ZSH that includes any and all customizations. I’m concerned that might cause problems with MacOS system ZSH. I can probably fix that with a custom login shell?
Anyway it’s fun, but complicated and diversely documented. Gonna take a while to sort it all out.
I use both NixOS and macOS. You can take two routes: 1. you can continue using Apple's /bin/zsh and just use a .zprofile generated using Nix (e.g. home-manager). Generally, the differences between zsh versions are not that large and it just works. This is what I have been doing with my Mac. 2. You could change your shell, either system-wide, or just for Terminal.app to ~/.nix-profile/bin/zsh.
I’ll eventually move to NixOS. I tried to run NixOS in VirtualBox, but couldn’t get screen resizing to work despite using the official ISO which is supposed to have the appropriate extensions installed.
If you have some leftover hardware, try it! NixOS is a different experience altogether and cannot be paralleled by Nix on macOS or a Linux distribution. Being able to declaratively define your whole system is insanely cool and powerful. Fully reproducible machines. Also, you can try out stuff without any harm. Just switch back to the previous working generation (or try the configuration in a VM with nixos-rebuild build-vm) if you are not happy.
Nix supports lots of approaches, with a varying degree of "buy in". I wouldn't say you're "supposed" to do one thing or another, although some things would definitely be non-Pareto-optimal (i.e. you could achieve all the same benefits with fewer downsides).
In the case of .zprofile, I would consider any of the following to be reasonable:
- A normal config file sitting on your machine, edited as needed, not version controlled.
- A symlink to a git repo of configs/dotfiles (this is what I do)
- Directly version-controlling your home dir in some way
- Writing the config content as a string in a Nix file, and having Nix put it in place upon rebuild (I do this with files in /etc)
- Having a Nix 'activation script' which copies/symlinks config files into place (this is what I do, to automate symlinking things to my dotfiles repo)
- Wrapping/overriding the package such that it always loads the desired config (e.g. by replacing the binary with a wrapper which prepends a "use this config" flag).
--
The following has nothing to do with your question, but I felt like ranting about a tangentially-related topic; it's not directed at you ;)
I often see "extremism" when Nix is brought up; e.g. if someone wants help managing non-Python dependencies of their Python app, and someone recommends trying Nix, it's often dismissed along the lines of "I don't have time to throw away my whole setup and start over with the Nix way of doing things, even if were better". The thing is, using Nix can actually be as simple as:
(import <nixpkgs> {}).runCommand "my-app" {} ''
Put any arbitrary bash commands here
''
Not at all. Apt has been able to remove everything for the last 20 years.
Not really. It can remove configuration files etc. it knows about, but it can't know about files later created by the application itself.
That's also not what's being asked for here. The basic request is this: track which packages were manually vs automatically installed, and give the user the ability to remove automatically-installed orphans whose manually-installed reverse-dependencies are no longer installed. This is what APT does and it works fine 99% of the time.
This list may include Firefox and other "end" software so a brain is required when parsing the list. You'll come to learn the relationships between packages and their dependencies and this will eventually become effortless.
EDIT: I'm wrong, see below.
> To remove a package and its dependencies which are not required by any other installed package:
> # pacman -Rs package_name
> To remove a package, its dependencies and all the packages that depend on the target package:
> # pacman -Rsc package_name
This is explicit rather than implicit but it works even on one package.
"How do I remove a package and all of its dependencies? [...] The package manager does not do recursive dependency removal on removal of a package. This error-prone automation will not be added to the package manager. "