Many years ago, when I first started working at Red Hat, I worked up a package management domain model diagram. I’ve referred to it many times over the years, but have never posted or explained it in detail. Recently, discussions over image building software caused me to refer to it a few times. Here it is, with annotations below.

• At the heart of the diagram is the package. A fairly abstract concept.
• A package has a powertype of PackageType. A PackageType is RPM, JAR, DEB, Docker, msi and so forth.
• A Package is composed of files.
• A package provides capabilities which fulfil dependencies, and has dependencies which are fulfilled by capabilities of other packages.
• A File is the contents, which can vary independently of a file name. A File name might be built out of a version string.
• A package is an abstraction. An actual RPM file is a instance of that package, but since a package can exist installed on a system, with none of the actual package files present, the FileType and PackageType are distinct abstractions. Still….seems there should be some implicit relationship there.
• A System is subscribed to a channel consuming an entitlement. This subscription provided access to the repository. Public repositories are not built this way, but SpaceWalk does this. I’ve not worked with Paid support for Ubuntu. I’d assume that Canonical has a related structure. Input gladly accepted.
• Errata probably should be moved over to the Package side as well. When a bug is fixed, and an errata is published, we want to make sure we have the files that contain the fix. This is directly referenced by a version of the package, via a version string matching a criteria: “Version V and Later contain the fix for bug XWZ.”

When I wrote this model, we were trying to unify a few different sorts of packages. Coming from SpaceWalk, part of the team was used to wokring on RPMS with the RPM Database for storage, and Yum as the mechanism for fetching them. The other part of the team was coming from the JBoss side, working with JAR, WAR, EAR and associated files, and the Ivy or Maven building and fetching the files.

We were working within the context of the Red Hat Network (as it was then called) for delivering content to subscribers. Thus, we had the concept of Errata, Channels, and Entitlements which are somewhat different from what other organizations call these things, but the concepts should be general enough to cover a range of systems.

There are many gaps in this diagram. It does not discuss the building of packages, nor the relationship between source and binary packages. It also does not provide a way to distinguish between the package storage system and the package fetch mechanism.

But the bones are solid. I’ve used this diagram for a few years, and it is useful.