User:Ffesti/comps

From FedoraProject

< User:Ffesti(Difference between revisions)
Jump to: navigation, search
(Comps.xml: Groups in F14)
(Comps.xml: move out F14 comps add section about different functions)
Line 3: Line 3:
 
'''Draft!'''
 
'''Draft!'''
  
The comps file adds meta data information to the repository that cannot be extracted from the packages themselves. Although there is one big tree of items there are several different functions merged into it. The structure of comps looks like this:
+
The comps file adds meta data information to the repository that cannot be extracted from the packages themselves. Although there is one big tree of items there are several different functions merged into it.  
 +
 
 +
See [[/F14|Fedora 14]] as example of the structure.
 +
 
 +
== Scheme ==
 +
The structure of comps looks like this:
  
 
* category
 
* category
Line 34: Line 39:
 
So there is a tree with fixed depth: Categories -> Groups -> optional packages.
 
So there is a tree with fixed depth: Categories -> Groups -> optional packages.
  
Categories (7) and groups (~70) in Fedora 14 (without language groups (~130)):
+
== Functions ==
 +
 
 +
Comps has several functions that are merged into the same tree:
  
* language-support
+
* Selecting packages as important to the user (in opposite to those only dragged in by dependency)
** *-support
+
* Grouping similar packages together to make them more easy to find
* desktops
+
* Grouping one of each kind together to allow installing them as one thing
** gnome-desktop
+
* Defining the default installation and default installation for variants
** kde-desktop
+
* Define how the UI for package selection should look like
** lxde-desktop
+
* Do magic for language packages (XXX TODO: read details about yum plugin doing this for F15)
** moblin-desktop
+
** sugar-desktop
+
** window-managers
+
** xfce-desktop
+
* apps
+
** authoring-and-publishing
+
** editors
+
** education
+
** engineering-and-scientific
+
** font-design
+
** games
+
** graphical-internet
+
** graphics
+
** office
+
** sound-and-video
+
** text-internet
+
* development
+
** development-libs
+
** development-tools
+
** eclipse
+
** electronic-lab
+
** fedora-packager
+
** gnome-software-development
+
** haskell
+
** java-development
+
** kde-software-development
+
** legacy-software-development
+
** mingw32
+
** ocaml
+
** openoffice.org-development
+
** perl
+
** ruby
+
** web-development
+
** x-software-development
+
** xfce-software-development
+
* servers
+
** clustering
+
** directory-server
+
** dns-server
+
** ftp-server
+
** legacy-network-server
+
** mail-server
+
** mysql
+
** network-server
+
** news-server
+
** printing
+
** server-cfg
+
** smb-server
+
** sql-server
+
** web-server
+
* base-system
+
** admin-tools
+
** base
+
** base-x
+
** dial-up
+
** fonts
+
** hardware-support
+
** input-methods
+
** java
+
** legacy-fonts
+
** legacy-software-support
+
** system-tools
+
** virtualization
+
* content
+
** books
+

Revision as of 10:58, 28 February 2011

Comps.xml

Draft!

The comps file adds meta data information to the repository that cannot be extracted from the packages themselves. Although there is one big tree of items there are several different functions merged into it.

See Fedora 14 as example of the structure.

Scheme

The structure of comps looks like this:

  • category
    • id
    • name (translated string)
    • displayorder (int)
    • grouplist (groupids)
  • group
    • id
    • name (translated string)
    • description (translated string)
    • display_order (int)
    • default (bool)
    • user visible (bool)
    • langonly (two letter lang code)
    • package list
      • conditional
      • mandatory
      • default
      • optionals

Anaconda magic:

  • whiteout
    • requires, pacakge
  • blacklist
    • packagename, arch


So there is a tree with fixed depth: Categories -> Groups -> optional packages.

Functions

Comps has several functions that are merged into the same tree:

  • Selecting packages as important to the user (in opposite to those only dragged in by dependency)
  • Grouping similar packages together to make them more easy to find
  • Grouping one of each kind together to allow installing them as one thing
  • Defining the default installation and default installation for variants
  • Define how the UI for package selection should look like
  • Do magic for language packages (XXX TODO: read details about yum plugin doing this for F15)