[jzwinck]

A package is a product, a cooked thing like Nginx. A configuration is ephemeral and site-specific, a dynamic thing like ~/.bashrc. You can claim the two are really the same, but no one else will understand what you are on about (is he saying we should hard-code more stuff?). We don't need exactly two categories here, but that seems the most idiomatic, and has done for decades.

Individual users may benefit from versioning their config files, but usually not their programs. Big business might do both, or just as likely screw it up and version code but not configs (I'm looking at you, crontab).

[snowwrestler]

Packages are far more ephemeral than people assume, because of the constant flow of security patches, bug fixes, and feature updates. If you're running a long-lived system, at some point those version numbers will matter.

I think the more useful way to think of packages and configuration are that they are necessary compliments. An unconfigured package doesn't do what you want, and configuration without a package doesn't do anything at all.

The theory is, they're both components of system state, so why not manage them together?

But to me it sounds like saying that text and layout are necessary compliments for a magazine, so why not manage them together? Because it turns out that is a horrible idea. Anyone who does professional publishing manages them separately.

"Do it all" tools rarely do it all well.

[derefr]

What he's talking about is likely this strategy: https://wiki.debian.org/ConfigPackages

If you follow it, you'll get a package like "mycorp-nginx", which is an atomic piece of configuration management that not only controls nginx's configuration wherever you deploy it, but also nginx's version on those same machines.

Basically, with this strategy, instead of installing nginx, you only install mycorp-nginx; the config-package then installs the thing it's configuring as a dependency. That dependency is locked to a specific version, so it'll only upgrade when you push out a config-package that changes that dependency.

[peterwwillis]

Some people 'cook' their configuration into packages because they aren't allowed to change the configuration on the target. You can also generalize 'automation' to mean configuration management, package management, job management, bug management, change management, deployment, monitoring, continuous deployment/delivery, continuous integration, and many other fields.

In practice, everybody screws something up, whether individually or part of a small/big business. The tools are typically not the problem; the humans and how they use them, are.