|
|
| (2 intermediate revisions by the same user not shown) |
| Line 3: |
Line 3: |
| 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. | | 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. |
|
| |
|
| | | This is the place for stuff that doesn't have it's own sub page yet. |
| == 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 ||colspan="3"| 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
| |
| |}
| |
