Why I put configuration management systems over packaging systems
A debate has broken out in the comments on my previous entry over whether you should manage system configurations through a configuration management system or through the system's package management. Although I once wrote a number of entries a few years ago in support of this view, I have now changed my mind and think that configuration management software does a better job for both pragmatic and high level reasons.
The pragmatics of the situation are clear: no packaging system today is really set up for this and so you can't really do it in practice. If they support features like overlays at all (and this is not common) the actual implementation is well below what you'd want. Nor is the foreseeable future likely to be any better; it seems very unlikely that any of the common package systems will add these features (often it would take significant changes in internal architecture to support this). So this idea is dead in the real world.
But even theoretically I think it's the wrong approach. To start with, the mechanics of managing a system via packages are awkward and indirect. You don't actually manage systems in any direct way; instead you assemble files, bundle them into packages, and queue those packages to propagate to systems where they do stuff. You need a whole infrastructure of 'action at a distance' things to make this work even in an ideal world with full package manager support.
(This is hard to see if you're only thinking about initial system setup because initial system setup looks simple; just install some packages and you're done. But that's not all you need to handle.)
The bigger problem is that managing through packages is working at the wrong level of abstraction. With packages you're forced to work at the very concrete level of files, package dependencies, and commands to run instead of at a level where you can write relatively abstract descriptions of the desired system state (which is what a configuration management system can let you do). Among other reasons, working at a relatively high level lets you actually express something close to your actual intentions instead of having them buried in a thicket of low level mechanics. You can also better describe various elements of state that are not easily represented as files to be shoved into places.
(All of my experience with configuration languages has convinced me that the more you hide intentions, the more things go wrong.)
PS: I'm assuming here that you can build all of the packages you need out of one version controlled directory hierarchy that has everything in it. This is at least theoretically possible and puts a package based system at par with modern CM systems that do work this way.