Yep, this exactly. If you want to make sure something is removed, like from a customer upgrade, leaving it in the configuration for a while is reasonable. Rea

Yep, this exactly. If you want to make sure something is removed, like from a customer upgrade, leaving it in the configuration for a while is reasonable. Really I wouldn't want untracked resources to be automatically removed - because someone might have had a reason for installing them. Though, yes, the question of removal of cruft does come up. However, if you are doing immutable systems, it's likely you are doing Ansible builds from something like Packer or aminator, and are doing red/green deployments that completely replace the OS. I think immutable systems are likely the future for applications, they just take some extra work to get your brain around them, that may make them be viewed as "not worth it" in some capacities - those dealing with a lot of data, needing to "stay around", legacy applications, etc. However, this is also why Docker is popular - because it's providing people a quicker way to get into the immutable system workflow. People have tried to make a better RPM in the past - I worked at a startup that did this at one point (rPath, now defunct). Though, ultimately, I think people want to work in higher level primatives than package managers, and the use cases involved in migrating a system from version A to version B are often not entirely clearcut. Configuration is also manageable by things like etcd - I think a new package manager is ... I guess conceptually interesting. But it's kind of the last thing I'd want. To control what versions you install, it can often be easier to just maintain good software repos, rather than enforcing it on each individual system. (Think databases). disclaimer: wrote Ansible