Upgrade forcing removal of kdebase4 packages

Hey Tubleweeders,

lately I had an Issue where upgrading to the latest packages and patches forced me to decide either to remove kdebase4-workspace-branding-opensuse and kdebase4-runtime-branding-opensuse and installing the quivalent upstream packages or downgrade a huuge pile of other packages to keep the current ones of kdebase4. After multiple tries on several days, I gave up and just did the proposed change to the kdebase4-upstream packages and noticed right afterwards that my openSUSE taskbar Icon changed to the Icon of KDE and boot loading screen has a completely different style now too.

Questions I would like to see answered and to learn something useful:

  1. Is this reversable somehow without going through all the friggin’ downgreade trouble?
  2. How come packages sometimes conflict each other when being on bleeding edge?
  3. What is the recommended way of coping with such behavior?
  4. For upgrading, I use a script containing “sudo zypper dup” - which piece of code to insert to avoid conflicts like above?

Thanks for all the help I’ll get on trhis thread, I hope it helps others as well!


It’s a bit of a pain when it happens. Although I haven’t had the problem recently with KDE, but have seen downgrades/re-upgrades happening with a few gnome3 packages. I don’t use a script, but I now always use “zypper -v dup” to see the detailed proposal showing version levels from and to. If it has issues I will wait a day or two to see if it’s resolved before committing the changes.

There’s a discussion of similar issues in an earlier thread, which you might want to read:

Quite so, and there are even earlier threads discussing KDE examples wrt branding package issues between Tumbleweed and standard Update releases.

Those packages get downgraded from 3.12 to 3.10 releases, and e.g. it breaks opening “pavucontrol” (seen more easily opening in a terminal). For those packages, a subsequent “zypper -v dup” has been upgrading them back to 3.12 releases.

To add to the beginning of my thread here, I re-installed my OS from scratch a few days ago as I decided to use the way of downgrading to keep my kdebase4-branding-opensuse packages. It then seemingly uninstalled half of my OS, leaving me with a f*cked-up login screen and a very simple terminal - many packages didn’t even work any more and I really wasn’t in the mood to search the web for a solution, I have other more important thing on my plate. Thus, I ended up with backing up all of my data and doing a fresh install. It did hurt a little, but hey, I love openSUSE too much to give up on it.

Thanks for your recommendation, I’ll update my script accordingly.

Does that mean if I issue “sudo zypper -v dup” that such breakages don’t happen? Or that downgraded packages get upgraded again?

I took the point to be that, with “-v”, you see what is going to be done. And you can abort (say “no” at the final confirmation), if it wants to do anything that looks as if it would cause a problem.

These days, I am doing:

# script
# zypper -v dup

and, that way, I have a transcript of the session in the “typescript” file. That’s useful when there are so many lines of output, that it scrolls off the screen.

No, It means that you can see more detail in the upgrade proposal/plan reported by zypper dup before you enter y/n to commit or abort.

If there is a conflict in resolving packages that zypper dup cannot solve, i.e when there is more than one possible solution, then it will report on those possibilities and offer you the choice. How will you handle that in a script, when you don’t know the choices in advance? You of can of course abort, and do it manually, and that then may require some investigation, including forum and/or Factory mailing list.

With those recent Gnome downgrades 3.12 > 3.10, there is just the one solution, but the normal choice to continue or abort is available. A second and subsequent zypper dup is required to go 3.10 > 3.12, but I don’t know the length of the interval required between the upgrades.

Question is, how to get back to the normal kdebase4-branding-opensuse packages without downgrading and uninstalling half of my system? Furthermore, I’d also like to stay on the bleeding edge. But then the next time I do “sudo zypper -v dup”, I’m forced to the same choice again. Inevitable? Or will this be fixed at a later point in time?

You could try what I did – message 9 in the earlier thread. I changed the repo priorities to give preference to the Tumbleweed and packman-tumbleweed repos. Some people are saying that’s the wrong thing to do, but at least it left me with a consistent system, including the opensuse branding for KDE4 and a working Gnome 3.12.

I thought this problem had undergone a compromise type of solution, as seen with the recent Gnome package down/upgrade where the correction interval is short. What is concerning me more is why you are now seeing this problem wrt KDE4 packages, I’m not at this time, and no-one else is reporting same at the moment(?).

I guess it depends on what one uses Tumbleweed for - testing versus “daily bread”, and whether you value/need the support of the Tumbleweed maintainer(s) when issues arise. If you use priorities, you probably won’t get it based on the way he/they run it themselves. It also depends on how confident one is in resolving package dependencies and how much time one has available to sort them out. However it’s still not recommended as general advice.

There are a few on the Factory mailing list who change priorities temporarily to effect a particular set of package updates, and then reset to equalize the priorities. Initially they got in a mess, and then after some discussion they learnt how to manage it. However it’s still not recommended as general advice even there.

IIRC, the so-called “official” supported position says to go with the downgraded upstream branding temporarily. Personally, I don’t like that and it arguably makes a normally reliable rolling release less than perfect.

Changing the priority of packman repo makes more sense to me, I always used to do it without issue, but haven’t bothered for some time since no problem has come to light without doing that.