I think you're misapplying the cornerstone of object-oriented software development, in which methods and data are coupled, to systems administration, where the paradigm doesn't really fit.

In software parlance, this idea violates what's called the "separation of concerns." Here, you can think of concerns as responsibilities. For the base operating system, packaging is the responsibility of the vendor, and configuration is the responsibility of the organization implementing the vendor's product. In most circumstances, unless you need to apply specific patches or change specific compilation options, you don't really want the product and the configuration to overlap where they don't need to.

It's true that you want to use one tool to do everything, but I don't see a compelling argument for why that tool should be the package manager. It seems much more logical from my perspective to wrap the package management functionality into the configuration management tool, rather than trying to shoehorn configuration management into package management. This is the approach taken by tools like Cfengine or Puppet, where most people will fold package prerequisites into the configuration management functionality so that the tool installs the requisite package first, and then applies the appropriate configuration.

Logically, you design a server configuration, and pick the packages to perform that function. You don't pick a bunch of packages at random and say, "hey, what cool stuff can I do with these packages?" It logically follows that the packages are subordinate to the business requirements imposed on the server, not the other way around.

Besides, if you're designing your configuration management in a well-structured way, it should behave more or less the same way on all platforms. It becomes much more difficult to rebuild a dozen packages when changing a configuration file than it is to simply alter a template and let your configuration management tool handle the rest.

While release management and configuration management do have substantial overlap, ITIL and other process frameworks draw important distinctions between them for a reason -- they're fundamentally different activities, which have fundamentally different implications, and often they're handled by very different workflows within the organization. When you're talking about systems management and maintaining responsibility for files living on a filesystem, you have to keep a distinction between software and configuration, between code and data, just like you already keep a distinction between static and volatile data. There's no compelling reason to combine the disciplines of release management and configuration management into a single entity when the goals and methodologies of the two are so different from one another.

--Jeff

I quite agree that you don't want to be rebuilding the vendor's packages just to roll your changes into them. That's why the package system shouldn't make you.

The problem with using a separate configuration management tool is that a good CM tool must reinvent and re-implement a great deal of functionality that a good package management system already has. I think that the amount of CM functionality that needs to be added to package management is smaller than the reverse.

(In my opinion, a good CM tool should be able to handle dependencies, versioning, and upgrades, and be able to tell you where a random file on your system came from and whether it's been changed from what it should be.)

The drawback to CM in the package management system is that it's not cross-platform. On the other hand, it doesn't hurt cross-platform CM (and it immediately helps people who only run one platform); at the best, the cross-platform CM can be an increasingly thin layer over the native CM capabilities.