What do package managers do? Install packages, obviously! But that is not everything. In my opinion, package managers do enough to be characterized as general automation frameworks. For example:
- manage configurations and configuration files
- manage custom compilation options and flags
- provide isolation or containerization
- make sure a specific file is present in a specific place given specific conditions
- change installation files or configuration based on architecture or other conditions
Not all package managers do all of the above, but you get the idea.
Nix even manages your entire setup with a single configuration file.
It occurred to me that package management could theoretically be managed by an automation framework.
What do I mean by automation framework? Ansible, chef, puppet, or Sparrow.
Now imagine if you were to use one of those package managers as an automation framework. For most of them, it would suck. (nix is a notable exception). So maybe common package managers are just bad automation frameworks?
What if we used an automation framework as a package manager? Well currently, it might also suck, but only because it lacks the package definitions. Maybe it is not a bad experiment to have a distribution managed by a modern automation framework like Sparrow.
What are the benefits?
- usable on other distributions
- more easily create your own packages on the fly
- Greater customization and configurability
- use a known programming language that is easy to read to define packages and other functions, instead of a DSL
- your package manager can easily automate just about any task using the same syntax and framework
What about using standard shell or bash? I know they are not easy to use correctly, but at least they won’t break every few years.
Great question!
Bash (on vanilla Linux) lacks functionality to verify each change after making it.
(Edit: For configuration drift detection, which I need in various contexts.)
Yes, I can verify each change I make, but it’s a huge pain in the ass in Bash. And in my experience, there’s a 100% chance the next person to update the config won’t understand that they need to update the matching verify step.
In contrast, in Ansible, every step has “modify” and “verify” modes built-in. If I change the “modify” step, the next “verify” run will be correct, automatically, because one config line defines both.
The closest thing in any shell, that I am aware of is “Desired State Config”, which currently only supports PowerShell. It currently leaves a lot to be desired. Configs in v1 and v2 are live code, which causes problems. But version 3 (currently in alpha) of Desired State Config looks quite promising (and is already designed to be an extension of Ansible and other orchestration engines.)
DSC, if it becomes an RFC, could become the best of both worlds. I dream of doing DSC in my preferred shell, to get started, then dumping those configs on a full scale orchestration pull-server, when I need it.
Edit: So many typos.
Not sure I really understand the issue here. Is it about installing or modifying parts of existing config files? I try to use config.d facilities as much as possible for this problem.
“Configuration drift” is when someone (often myself, in a moment of inattention) manually changes things from how I want them.
I need to keep drift to a minimum, because I often build machines that are extremely similar to the previous build - and I won’t remember the manual change next time, unless I detect the drift and correct it in my configuration management solution.