I’d like to bring to your attention one of those small details of a distribution that most people never really notice – and if that happens, we might have done a good job behind the scene ;-).
The YaST package manager groups the packages into various groups. Until 10.1 we used a concept called “selections” and switched with Alpha3 of openSUSE 10.2 to “patterns”. Full details of patterns are are available at the openSUSE wiki.
- Patterns include a list of software packages to install.
- The list of software packages contains packages that are:
- required (must-have, will always get installed if the pattern gets installed)
- recommended (should-have, will get installed if the pattern gets installed but users can deselect it)
- suggested (may-have, will not get installed if the pattern gets installed but users can select it)
- In the future, we would like to drive work flow with patterns as well. For example, if you select the (imaginary) LDAP server pattern, the LDAP configuration work flow 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.
You might wonder why I consider patterns that important since they are only used during installation of packages. There are various reasons:
- They help to structure the system: 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?
- With optional packages, the users sees what else might be interesting – while others can still have a minimal system.
- It’s easier to tell users “install the LAMP pattern” instead of giving them a list of more than a dozen different packages.
- We can create media like CDs as just a collection of patterns with their dependencies. Note this works also the other way around: All packages on a CD might be just a pattern.
- New users know what they want to do with their system, e.g. setup a LAMP server but they might not know exactly which packages to install. With patterns – as with selections – we guide the user.
During the last two months a lot of discussions about patterns have happened on the openSUSE-factory mailing list (see the archive). With Alpha5 coming out this week, you’ll see the current status and I hope to be 90 per cent finished with it so that only a few more patterns might be added and patterns will get additional packages as necessary. With the number of patterns, it’s important to structure them properly. There’s a simple hierarchy where a pattern belongs to a role like “server functions”. Also some of the patterns will not be visible directly to the user, they will get folded into others to make the list smaller – but internally they are separate. Patterns are really powerful. I’ve defined for example three graphics patterns: A generic one, a GNOME specific one and a KDE specific one. If a user selects the generic pattern, then the desktop specific ones are selected automatically, so that if you have selected GNOME, you get the GNOME specific graphic pattern as well. If the user now switches from GNOME to KDE the specific graphic pattern is changed as well. Currently development is going on in the pattern dialogs to present the patterns in an easier way. A few small changes might get implemented:
- Optional packages will be in a light grey to distinguish them from required packages
- The hierarchical tree structure can be folded and unfolded, e.g. all development patterns might be hidden initially until the “development” role is opened.
- The packages from totally invisible pattern can be shown in their parent. With the graphics example above, the user might only see one graphics pattern that consists of packages of all three graphic patterns (if we make the two desktop specific patterns invisible) – but the selection logic and resolving is done on the basic patterns.
Our usability experts are looking into further, more radical, improvements for the dialogs but this is beyond 10.2. I’m looking forward to further discussion of patterns on the openSUSE-factory mailing list after openSUSE Alpha5 is out. There will always be some use cases that our defined patterns cannot satisfy but I hope that we get the most common use cases perfect, so please play around with them in Alpha5 and report how you like it.