Patterns

From openSUSE

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

Patterns for 10.2

Alpha5 will use these roles and patterns:

• Base Technologies
  • 32bit: 32Bit Runtime Environment (only on ppc64, x86-64)
  • 64bit: 64Bit Runtime Environment (only on ppc)
  • apparmor: Novell AppArmor
  • base: openSUSE Base System
  • console: Console Tools
  • laptop: Laptop
  • x86: x86 Runtime Environment (only on ia64)
  • yast2_basis: YaST System Administration

• Graphical Environments
  • gnome: GNOME Desktop Environment
  • kde: KDE Desktop Environment
  • xfce: XFCE Desktop Environment [only ftp/DVD]
  • x11: X Window System
  • fonts: Fonts

• GNOME Desktop
  • gnome_admin: GNOME Administration Tools
  • gnome_basis: GNOME Base System
  • gnome_ide: GNOME Development Environment
  • gnome_games: GNOME Games
  • gnome_imaging: GNOME Graphics
  • gnome_laptop: GNOME Laptop
  • gnome_multimedia: GNOME Multimedia
  • gnome_office: GNOME Office
  • gnome_utilities: GNOME Utilities
  • gnome_xgl: GNOME Desktop Effects

• KDE Desktop
  • kde_admin: KDE Administration Tools
  • kde_basis: KDE Base System
  • kde_ide: KDE Development Environment
  • kde_edutainment: KDE Edutainment
  • kde_games: KDE Games
  • kde_imaging: KDE Graphics
  • kde_internet: KDE Internet
  • kde_laptop: KDE Laptop
  • kde_multimedia: KDE Multimedia
  • kde_office: KDE Office
  • kde_system: KDE System
  • kde_utilities: KDE Utilities
  • kde_xgl: KDE Desktop Effects

• Desktop Functions
  • games: Games
  • imaging: Graphics
  • remote_desktop: Remote Desktop
  • xml: XML and LaTeX Editing Tools
• Server Functions
  • dhcp_dns_server: DHCP and DNS Server
  • directory_server: Directory Server (LDAP)
  • file_server: File Server
  • gateway_server: Internet Gateway
  • lamp_server: Web and LAMP Server
  • mail_server: Mail and News Server
  • misc_server: Misc. Server
  • network_admin: Network Administration
  • print_server: Print Server
  • xen_server: Xen Virtual Machine Host Server

• Non-OSS Software
  • non_oss: Misc. Non Open Source Packages (only on NON-OSS Media)
  • non_oss_java: Java Environment (only on NON-OSS Media)

• Development
  • devel_basis: Basis Development
  • devel_C_C++: C/C++ Development
  • devel_gnome: GNOME Development
  • devel_ide: Integrated Development Environments
  • devel_java: Java Development
  • devel_kernel: Linux Kernel Development
  • devel_kde: KDE Development
  • devel_mono: .NET Development
  • devel_perl: Perl Development
  • devel_python: Python Development
  • devel_qt4: Qt4 Development
  • devel_rails: Rails Development
  • devel_rpm_build: RPM Build Environment
  • devel_ruby: Ruby on Rails Development (not on CDs)
  • devel_web: Web Development
  • devel_yast: YaST Development

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.

Describing patterns

The current way of describing pattern is via .pat files. However, this is actual a concrete implementation for YaST style repositories and not useful for e.g. repomd type repos.

Ideally, some kind of pattern definition language should be used which is

• easy to write
• easy to read
• easy to process

See pattern definition language for a proposal.

Pattern content

All of the above discussion about patterns in openSUSE 10.2 takes the top-down approach, without actually talking about packages.

The pattern content page tries to go the reverse path by discussing how to group packages to patterns.

See Also

• Proposal for general framework