Package Handling
This is about what to do with packages. This does not include packaging (creation of packages and spec files). So scope is from RPM up to package GUIs and provisioning tools.
Tools Layers
The package handling stack consists of a number of different tools which are interconnected and using and building on each other. Defining a layer model is a way of understanding the interfaces and if everything is in the right place.
This is still a draft!
- Layer 0: Build packages
- Layer 1: Install and remove packages
- Layer 2: Repositories and depsolving
- Layer 3: Groups and applications
- Layer 3.5: Process separation and abstraction
- Layer 4: UI and management
Layer Zero: Build system
The different build systems are out of the scope of this document. There are a couple of issues wrt build system rewquirements and rpm that are worth discussing. One being the fact that source rpms may depend on the arch they where build from and that there is no other sane way to determin the build requires of a package than building the source rpm on exactly this arch.
Layer One: Packages
This layer does install and remove packages. It's responsibility is to check requirements and to reject a transaction on errors. It also offers a per single file on the disk management and verification.
Tools in this layer: RPM (dpkg, ... for other distros)
Layer Two: Repositories and depsolving
This layer takes care about what packages are needed for the current operation and where to get them. This includes the repositoriy format and may be even the mirror handling and the dispatching to the mirrors
Tools: createrepo, yum, rhn-plugin
Layer Three: Groups and Applications
This layer provides additional information about packages - selecting the ones the user should be interested in. It puts the packages into categories and groups them together so they can be selected and installed in one bunch to provide a given functionality or selection of applications.
Also information about updates and patches is also belonging into this layer.
Layer 2 and 3 are both implemented within yum. SO there is not really a tool boundary but more of a logical separation
Tools: yum
Also see: AppStream, comps.xml, updateinfo.xml, Open Collaboration Services API (for AppStream)
Layer Three and a half: Process separation and abstraction
Most GUI or management tools need a separation from the backend. One reason for this is making the front end run at a different privilege level (user vs root). Another is gaining more concurrency as the Layer 3 tools are typically not very well suited for GUI operation. This separation is often just part of the layer 4 tools (e.g. in yumex) or just missing completely - this is the reason why this layer doesn't get it's own major number.
PackageKit is an abstraction layer that offers - beside the separation mentioned above - an abstraction layer for different Layer 3 backends - including non rpm stacks. The project also contains components for layer 4. As PackageKit is comparably young there are not many other Layer 4 tools built on top. There is a corner use case where "normal" applications need package handling capabilities for offering access to plugins or extensions in which PackageKit has gained some traction.
Layer 4: User interface and management
Everything thats builds ontop of Layer 3: Package GUIs, updaters, system provisioning tools, software management tools.
Command line interfaces would also be in this layer, but most tools of lower layer tools provide their own command line interface with functionality limited to their own and (some times restricted) lower layers.
Data Layers
For the data the layering is slightly different. The data layers are relevant from the users view and the model may help when designing UIs.
- Layer 0: Source packages
- Layer 1: Packages
- Layer 2: Applications
- Layer 3: Groups
- Layer 4: Repositories and Products
- Layer 5: Repository Registry (Does not exist yet)
Layer 2: Applications
Right now "applications is basically just a sub set of packages that have been selected as "interesting for the user to install". Typically this excludes libraries and development packages (although they are interesting to install for developers) but includes services that might be selected by hand like web servers.
The AppStream project aims for making this layer more rich by actually adding informations to the packages selected.
Layer 3 Groups
There is some confusion in the Fedora/Red Hat world what a group is as the same term and data structure is used for two things:
- Categories to put applications in (putting together similar applications)
- Creating a entity that can be installed at once providing a larger scale functionality (putting together one of each kind)
For the scope of this layering we will probably still need to divide these two into separate layers.
Layer 4 Repositories
The community distributions are aiming at making the need for this layer to go away. Especially Fedora has an attitude of telling the users that their own repositories are the only once to be used. IN an enterprise environment it might be desirable to have a large number of 3rd party repositories as a way for 3rd part vendors to offer their software.
Layer 5 Repository Registry
As far as I know such thing does not exist right now. In a world of lots of repositories this might be necessary but we are not in this world.
| Layer | Entities in Distributions | |||
|---|---|---|---|---|
| Community | Enterprise | Installed | ||
| 0 | Source | 10k | 2k | - |
| 1 | Packages | 20-30k | 3k | 1-2k |
| 2 | Applications | 2k | 1k (?) | 100? |
| 3 | Groups | 30-100 | 30-100 | 10 |
| 4 | Repositories | ~5 | (?) | 1-3 |