(Moved from PackageHandling page) |
|||
| Line 21: | Line 21: | ||
Tools in this layer: RPM (dpkg, ... for other distros) | Tools in this layer: RPM (dpkg, ... for other distros) | ||
=== Layer Two: Repositories and depsolving === | === Layer Two: Repositories and depsolving === | ||
Revision as of 08:58, 16 February 2011
Tool 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.