This one has been in my queue for ages .. well.. 3+ months or so .. but still..
Over at dev2ops an article was posted with as title Pacakge Centric Application Release Methodology.
And it's that Application Release part which is actually the focus point.
The Application being split up in different parts where different teams have responsibility over those parts and having isolated packages for these parts is a good thing.
But you can easily confuse that naming of a package with the way a systems person looks at a pacakge, a deb , or an rpm. And then the story changes a lot.
They list the contents as a packge as follows :
What belongs in a package?
* Code: Application files executed by the runtime system. This could be compiled objects or interpreted script.
* Platform: Files that comprise the runtime layer. This is generally server software like Apache, JBoss, Oracle, etc.
* Content: Non-executed files containing information. These could be media files or static text.
* Configuration: Files defining the structure and settings of an online service. These could be files for configuring the runtime system or the application.
* Data: Files containing data or procedures for defining data. These could be database schema dumps, SQL scripts, .csv files, etc.
* Control: Configuration and procedures consumed by management frameworks
Now I`m convinced that not all of this content belongs in an RPM or Deb.
Config , Content and Data don't belong there at all.
Yet they have to be delivered as a package by the development team, we need to know what the deliverables are they have to provide us with. But on a system, if you autorize change to content or config you don't want our package management system to keep telling you it's checksums have changed.
Within the package-centric paradigm, each type of change noted above is bundled, distributed and executed via a package.
Executed ? You don't want your package management system to do this .. that's exactly what your configuration management platform isi supposed to do isn't it ?
On a systems level you really want to separate code, data and config.
So dev2ops is talking about a package from a developer point of view, which is a totally different view as the one from a sysadmin ...
