Just a quick note to everyone using factory and wonder what patterns-openSUSE-kde4_basis is all about: our patterns install packages now.
To explain this change, I need to get a bit back in history: In openSUSE 11.0 we did a change that is still significant: we do no longer install patterns. In older releases, when you installed a “KDE Desktop” or a “GNOME Desktop”, yast would save that information as “pattern”. Patterns are basically groups of packages, but they can also depend on other patterns. They have a clear semantic when you install: “KDE Desktop” -> kdebase4-workspace, kdelibs4, amarok, …. Some describe them as “Macros for packages”. But there is still no clear semantic on removing a pattern as this relation between “KDE Desktop” and amarok is only in one direction. If you remove “KDE Desktop”, it’s not clear if you want to remove amarok too or if if should stay on your LXDE. So we decided to go away from installing patterns to make this clear: There is no way to remove a pattern as it’s never installed. It’s only “satisfied”, meaning a pattern can express that it’s not satisfied without amarok installed. So if you decide to remove amarok, the pattern will be left unsatisfied (appears as not installed).
As I said: openSUSE 11.0 and 11.1 do this and there are little problems associated with it. But now that we support “zypper dup”, it came clear that you will not get the same “KDE Desktop” on 11.2 if you do an update or an installation. This is kind of okay, but not how it should be: most users see a distribution upgrade as an installation without the need to start from scratch. The reason for this difference is that there is no information left that you have a “KDE Desktop” after you changed repositories (patterns only appear in the repository, not in the system). Now assume the 11.2 “KDE Desktop” needs dolphin too, otherwise you get only an ugly gray square (not true, but we assume it). The solver will see amarok and update it to the newest version, but as it doesn’t see a “KDE Desktop”, it won’t install dolphin.
So for openSUSE 11.2 I changed the patterns to generate packages with cryptic names to install along with the pattern. So if you install “KDE Desktop” on 11.2, it will install amarok, dolphin and patterns-openSUSE-kde4_basis. If you do zypper dup on openSUSE 11.3 (or factory in january) the solver will see patterns-openSUSE-kde4_basis and know the new requires of the new version and install e.g. choqok.
That doesn’t solve the 11.1->11.2 update case, but after updating to 11.2, you can reselect the patterns you want and you can be sure they will stay from now on. And perhaps we do an online update for 11.0 and 11.1 that will add patterns packages to the most prominent use case: the desktops.
Both comments and pings are currently closed.
I did not understand very well the explanation you gave about patterns, but I noticed that since release 4.3.1 of KDE there is a problem of co-existence between packages of KDE4 and KDE3. Under KDE3 I do not see anymore the categories of applications in the kickoff and whenever I launch Kcontrol or Kinfo the same phenomenon occurs.
What do you think about that?
Thanks in advance for providing the users with useful technical informations about the changes in system management.
Have a lot of fun
Your problem has nothing to do with patterns, but the simple fact that KDE3 is unmaintained. Noone cares about it, so such bugs appear naturally.
As a member of the openSUSE development team, do you think that KDE4 is as of today mature enough to replace KDE3 in our favorite distribution? I am using the repository of the OBS and I sill find there newer packages in the folder openSUSE_Factory. I know that KDE3 will not find the way in the next release of the distribution but this is obviously not the case in the OBS. So, what do you meant with absence of maintenance?
I will give you now my opinion about the future releases of openSUSE Linux: With all the respect due to the development team and the KDE team, we are going to wait very long for a rock-solid openSUSE without KDE3 as the default desktop.
Anyway openSUSE Linux is unbreakable. Have a nice evening and a lot of fun …
The KDE3 repo is rebuild against factory/11.2, but no bugs in it are fixed.
I finally discovered the patterns packages today after an update again the new upstream of the Factory repository and I found the idea behind very interesting. The single problem I faced with their introduction is that selecting a pattern means installing automatically not desired packages as well ( a desktop user would like avoiding the installation of beagle due to its high resource consumption).
I suggest the usage of the patterns at a lower level in the particular case of the desktop environments allowing a more restrictive selection of packages according to their general purpose; Development, Multimedia, Games, Internet etc. Maybe this is a nonsense but I am committed as a user to contribute to the development of our beloved openSUSE Linux with ideas like this,
Thanks a lot to all of you for the job you are doing. Have a nice evening and a lot of fun …
Does this mean that KDE3 will not work with openSUSE 11.2? That would keep me from upgrading for a while.
Hey, KDE3 does work with 11.2! I have installed it from the KDE:KDE3 repo.
The system uses half the memory and boots much faster than with KDE4. Many thanks for working on KDE:KDE3!
This news looks like a “welcome to the wonderful world of meta packages” which are available for Debian and Fedora based Distributions since a really long time now.
The question for me is: is a pattern simply a meta package requiring other packages/patterns?
In this case, it might be a good decision to follow the way of other distributions and use meta-packages for that.
But I can imagine other things, that could be covered via patterns – especially during installation. What about a pattern not only requiring packages but also telling YaST: “If the user selects me, please run the following application afterwards”. Think about “Start the YaST2 webserver module if a user selects the ‘webserver’ pattern” as simple case. If it’s YaST module, it could be integrated in the normal installation workflow as example. This could obsolete the installation.xml file needed to “patch” the control.xml (the file which controls the installation workflow) for add-ons and allow users to modify their installation even before the first package is installed.
Is this an idea that’s worth working on?