Corollary: make it easy on yourself: mount /home separately (and maybe /var too), and keep /etc in scm.
I wish there was more rigor (and testing) with this sort of thing. Generally systems should have the invariant that “install old” + “upgrade” == “install new”. This property can be fuzz tested with a bit of work - just make an automated distribution installer, install random sets of packages (or all of them), upgrade and see if the files all match.
/etc makes this harder, since you’d want to migrate old configuration files rather than resetting configuration to the defaults. But I feel like this should be way more reliable in general. And people want that reliability - if the popularity of docker and nix are anything to go by.
For example a new system won't have pulseaudio, but it won't be removed and replaced automatically because that would be potentially disruptive to existing users.
> The greatest OMFGFFS in this realm, by far, came with the big lurch over to systemd.
I think by the time I started with it, NixOS was already on systems, but reportedly that transition went off without a hitch. Before the transition, NixOS configs were in charge of generating OpenRC scripts or whatever, then afterwards the same configs generated systemd units instead. When the system has total control over the config files like that you get to bypass certain challenges!
You might notice that the old announcement for that feature includes no special care other than the requisite reboot to change init systems: https://web.archive.org/web/20200423143059/https://releases....
https://blog.jak-linux.org/2023/10/10/a-case-for-different-u...
The problem is that's not really true. i.e. consider you get postfixed pulled in by postfix | mail-transport-agent and the new distro release changes it to exim4 | mail-transport-agent as we picked a new default MTA.
Does this mean we should, by default, replace your MTA and require you to have to configure a different one?
You will be able to do this (pick the same automatically installed packages given the same set of manually installed ones; installing missing Recommends, etc, by using --fix-policy and some more options perhaps).
As for configuration this is worse, files managed by ucf have 3-way merging but it's not automatic and most configuration isn't managed by ucf but by dpkg.
The installed packages can be listed with `dpkg --get-selections`, and that list can be replayed should it be necessary to recreate the installation, plus a backup of /etc/. But I never had to do this, Debian just works.
That said, I may do a speculative dist-upgrade on a snapshot to reveal & prepare for conflicted conffiles in advance, but I'll throw that away, I won't rely on the merged result across a release upgrade.
Shame that the only bistro that lets you do this is extremely arcane and difficult to learn if you do not have a PhD in mathematics.
Hey, there are two! Remember GuixSD
I don't begrudge any Guix contributors protesting that the GuixSD docs are undersold by such hyperbole, though! If that's you, carry on. :D
The so-called "atomic" distros don't attempt to make the (config -> state) transformation reproducible but rather sidestep the problem by snapshotting and replicating the output of the transformation -- the files on disk after various installs, upgrades, and config changes.
1. Find ways to automate setting up my env. Keep that instruction current. apt and chocolatey/ninite have made this far simpler than it used to be. 2. Keep data in directories that are auto-backupped. Concretely I have everything in 'shares', and these shares have survived various changes in tooling, buut their location and principle have stayed the same. Also helps organizing your files :) 3. Have short but precise instructions on how to setup new envs, wherever automation isn't possible or impractical.
Has worked for me for decades now, and it means I'm good to go within an hour of (re)installing a fresh OS.
I think nix has something similar. I wish Debian/ubuntu had something like that - maybe it does - but I’ve never figured it out.
The list of manually installed packages is effectively the "world".
The new solver takes inspiration from apk in that it marks the world/manually installed packages the root of the dependency problem (hence why they can't be removed by the solver itself, only manually).
aptitude search '?installed ?not(?automatic)'
There's probably a way without aptitude, but using Debian without aptitude is like riding a bicycle without gears.