Cool Solutions

Software Groupings for Installation – or Patterns


October 1, 2006 2:38 pm





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.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Categories: Uncategorized


Disclaimer: This content is not supported by Micro Focus. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.


  1. By:flyingGuy

    Oh how cool!

    A pattern of a pattern of a pattern of a pattern of a pattern of a pattern of a pattern of a pattern …

    Did ya get your doctorate yet?

    Massively more complex systems lead to massively more complex errors until a single point of failure brings this whole house of cards craching down.

    RPMS have been figuring out dependencies LONG before this latest buzzword came along and will still do it long after this latest buzzword fades away into the dust that all esoterica falls into, sooner, or later.

    Is this a sub-pattern of pattern X which is reall only a sub=pattern of pattern Y which is evolved from a sub-pattern of pattern A for which pattern X is dependent upon?

    Dependency is a straight forward deal. I you want software program X installed under environment G it needs lib H, Lib H needs lib’s D,K and L thats as complicated as it gets. The end of the dependency tree is just that, the end.

    Throwing yet another level of verbs and nouns wont make it easier or simpler, all it does is make more completity for people to have to figure out and digest as if we dont have enough to do already.

    Someone needs to publish their Doctoral Thesis, get their title, then get a job doing real work.

    – Bill

  2. By:Andreas Jaeger

    We still use the dependency resolution way, so patterns will not include dependend packages.

    RPM does not resolve dependencies, it only informs you about them.
    Resolving would mean that rpm -i package would install all needed packages as well. But it only tells you that it cannot satisfy its dependencies.

    Btw. you can just switch to the list view and install single packages if you prefer.

  3. By:Eric Young

    Is there a chart or something that compares features of selections vs patterns? Exactly how are patterns better than selections? Or is it simply a name change? The wiki page, linked to above, does not really go into it. If patterns are more useful than selections, is there any chance that patterns will make it into OES 2?

  4. By:Andreas Jaeger

    No, there’s no real comparison like this. It’s not only a name change but also more semantics, my list above lists the major changes.

    All future openSUSE products as well as products based on our SUSE Linux Enterprise 10 products will use patterns. The SUSE Linux Enterprise Server 10 and SUSE Linux Enterprise Desktop 10 were the first products to use patterns – and you cannot mix patterns and selections.

  5. By:flyingGuy

    Resolving -v- Informing

    OK, so you say tomato I say Tomahto. I assert it resolves the dependency to a lvel of 1.1, your assertion is that “patterns” resolve the dependency to a level of 1.0.

    If you have created a program, that essentialy has a database of depencies that upon installation installs all dependent modules, libs, programs, what have you, that is GREAT as it saves me a step.

    What I find useless and pointless is to take a word like “pattern” which in and of itself desrbies almost nothing because it describes almost everything and use it like it is some great new invention or process.

    For example, if you asked a person how they set up their iptables and they answer, “We use Patterns!” they have told you nothing, imparted zero knwoledge. For that matter the word “patterns” could be used to answer pretty much ANY query about a process and in reality you reply would be absolutely meaningless without a modifying verb, which would then lead to a discussion about how you create the database and tell the installer to go and fetch the appropritate lib, module, script etc. etc.