Post B5YMpFe9ObIT4ChMxs by mid_kid@fosstodon.org
 (DIR) More posts by mid_kid@fosstodon.org
 (DIR) Post #B5YMpF4LXienH9wm9o by mid_kid@fosstodon.org
       0 likes, 0 repeats
       
       Most #gnu #linux package managers have the necessary metadata to "restore" or "reset" a system to a (previous) known working state without immutable or btrfs snapshots:- A list of desired packages, from which a full list of packages can be constructed using dependency information- A listing of every file that should exist in PM-managed locations like /usr and /etc- A hash of each of these files, allowing to check integrity and detect /etc modificationsOld design decisions prevent this.
       
 (DIR) Post #B5YMpFIWh001z8a6G8 by mid_kid@fosstodon.org
       0 likes, 1 repeats
       
       A few design decisions make this difficult.The biggest is post-installation actions. /usr often contains files that are dynamically generated after install. These are often caches that need to be regenerated when packages are installed/removed. Alongside this, some packages perform one-time initialization - moving some file here, enabling some service there. Many package managers conflate the two kinds of actions, making it difficult to know how to re-generate the files without reinstalling.
       
 (DIR) Post #B5YMpFe9ObIT4ChMxs by mid_kid@fosstodon.org
       0 likes, 1 repeats
       
       Some package managers, especially those geared towards "expert" linux distributions, keep the post-install initialization actions to a minimum, leaving it to the sysadmin, or moving it to a separate tool/script.Other package managers correctly distinguish the two kinds of actions, by providing a "trigger" mechanism, that fires a repeatable script whenever a package modifies specific directories. This can be seen in at least dpkg, pacman and alpine's apk.