The wikis are now using the new authentication system.
If you did not migrate your account yet, visit https://idp-portal-info.suse.com/

Patterns

Şuraya atla: kullan, ara

Patterns

Currently in SUSE Linux 10.1 (and earlier releases) we use selections in YaST to group software and easily enable installation of related software.

Our developers have now enhanced the concept of selections and call it patterns.

What are Patterns?

  • Patterns include a list of software packages to install.
  • The list of software packages contains packages that are:
    • required (must-have)
    • recommended (should-have)
    • suggested (may-have)
  • Patterns define a type of functionality the system should have. They do this by either directly naming required packages, by grouping of sub-patterns, or a combination thereof. This partitions the huge list of installed rpms into building blocks that can be combined (almost) at will. By listing each and every rpm in a (ideally, exactly one) pattern, this relates rpms to functionalities. This in turn finally provides the answer to the often asked question: "Why is this package installed?"
  • In the future, we would like to drive workflow with patterns as well. For example, if you select the (imaginary) LDAP server pattern, the LDAP configuration workflow will be called during installation.
  • Patterns can be grouped into roles, like "Development" or "Desktop".
  • Patterns can require other patterns. They have the same set of (possible) dependencies as packages have. So they can also obsolete (replace) or conflict with other patterns, or have language dependencies, and so on.
  • Add-on products can have additional patterns.
  • Patterns can be differentiated between top-level/user-visible and internal/non-user-visible patterns (a pattern might require others that are not visible). These are implementation details of the patterns.

From Selections to Patterns

Directly after 10.2 Alpha2, I'd like to switch to patterns. Instead of simply rewriting the existing selections to patterns, I would like to start basically from scratch and define with you which patterns we should have.

Selections in 10.1

Currently we have the following selections:

  • Graphical Base System
  • KDE Desktop Environment
  • All of KDE
  • GNOME System
  • Help and Support Documentation
  • Office Applications
  • Games
  • Multimedia
  • Voice over IP
  • Xen Virtualization
  • Simple Web Server with Apache2
  • LDAP Server and Tools
  • Network and Server
  • Laptop
  • Mobile Computing
  • C/C++ Compiler and Tools
  • Kernel Development
  • KDE Development
  • GNOME Development
  • Tcl/Tk Development System
  • Java
  • Experienced User
  • LaTeX, SGML and XML
  • Fonts
  • Mono/CLR
  • Non-Open Source Packages

First Proposal for Patterns for 10.2

As a first step for discussion I propose these roles and patterns:

  • Graphical Environments
    • GNOME Desktop Environment
    • KDE Desktop Environment
    • XFCE Desktop Environment
    • X Window System (with fvwm2)
    • X Window System (with Windowmaker)
    • X Window System (with ...)
    • CLI only enviroment
  • Base Technologies
    • Base System (always installed)
    • AppArmor
    • Xen Virtual Machine Host Server
  • Development
    • C/C++ Compiler and Tools
    • GNOME Development
    • KDE/QT3 Development
    • Qt 4 Development
    • Linux Kernel Development
    • Version Control Systems
  • Primary Functions
    • File Server
    • Print Server
    • Mail and News Server
    • Web and LAMP Server
    • Internet Gateway
    • DHCP and DNS Server
    • Directory (LDAP) Server
  • Secondary Functions
    • Office enviroment (OOo, Email, web)
    • Games for 2d video card
    • Games for 3d video card


This misses some of the selections and introduces new ones. This is really a first step for discussion. I would like you to come up with better high-level proposals!

Let's not discuss "we need this pattern as well" - but let's discuss and agree on the general framework and then let's discuss adding further patterns.

Btw. we have a nice way of adding new, third-party patterns: Basically all you need is to have a lightweight add-on product that only has patterns, but no RPMs. So one could create his or her favourite package collections and make them available as an add-on source. Every repository can add patterns.