3 ms·

> The healthy choice is to rebuild rather than upgrade any long-lived OS installation (e.g. your desktop) on distro release. I wish there was more rigor (and t

> The healthy choice is to rebuild rather than upgrade any long-lived OS installation (e.g. your desktop) on distro release. 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.

LtWorf 2y ago
In theory yes, but this hits with the fact that defaults change. 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.
inopinatus 2y ago
Alas that many packages will not upgrade conffiles gracefully when their structure/semantics change, and many are beyond the ability of any package manager's built-in diffing tools to apprehend. That is why I place /etc under scm for long-lived hosts, because what happens next instead looks an awful lot like doing a conflicted three-way code merge following a breaking-change vendor release. The greatest OMFGFFS in this realm, by far, came with the big lurch over to systemd.
- pxc 2y ago
  related: https://etckeeper.branchable.com/ https://etckeeper.branchable.com/ > 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.nixos.org/nix-dev/2013-January/010482.html https://web.archive.org/web/20200423143059/https://releases....
julian-klode 2y ago
This is a very contentious topic, you can see my initial take on this in https://blog.jak-linux.org/2023/10/10/a-case-for-different-upgrades/ 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.

LtWorf 2y ago

In theory yes, but this hits with the fact that defaults change. 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.

inopinatus 2y ago

Alas that many packages will not upgrade conffiles gracefully when their structure/semantics change, and many are beyond the ability of any package manager's built-in diffing tools to apprehend. That is why I place /etc under scm for long-lived hosts, because what happens next instead looks an awful lot like doing a conflicted three-way code merge following a breaking-change vendor release. The greatest OMFGFFS in this realm, by far, came with the big lurch over to systemd.

pxc 2y ago
related: https://etckeeper.branchable.com/ https://etckeeper.branchable.com/ > 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.nixos.org/nix-dev/2013-January/010482.html https://web.archive.org/web/20200423143059/https://releases....

julian-klode 2y ago

This is a very contentious topic, you can see my initial take on this in https://blog.jak-linux.org/2023/10/10/a-case-for-different-upgrades/ 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.