User:Ffesti/PackageHandling

From FedoraProject

< User:Ffesti(Difference between revisions)
Jump to: navigation, search
(Tools Layers: Move out Tool Layer)
(Data Layers: Moved out)
Line 2: Line 2:
  
 
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.
 
 
 
 
== 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
 
|}
 

Revision as of 08:54, 16 February 2011

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.