Dependency Hell!!!

I’ve run;

sudo zypper dup --from Tumbleweed

command since setting up Tumbleweed repos 6 months to a year ago, however I was recently advised on these forums every now & again to run;

sudo zypper patch

which currently results in a never ending circle of dependency hell! I have stuffed up my install, the SUSE branding disappeared, (which I thought was just a new look.) Anyway restored from recent backup, but not sure how to proceed;

 fleamour@E325:~> sudo zypper patchroot's password:
Loading repository data...
Reading installed packages...
Resolving package dependencies...
2 Problems:
Problem: kdebase4-workspace-4.11.1-6.8.x86_64 requires kdebase4-workspace-branding = 4.11, but this requirement cannot be provided
Problem: gtk2-branding-openSUSE-12.2-4.4.1.noarch requires libgtk-2_0-0 = 2.24.18, but this requirement cannot be provided


Problem: kdebase4-workspace-4.11.1-6.8.x86_64 requires kdebase4-workspace-branding = 4.11, but this requirement cannot be provided
  uninstallable providers: kdebase4-workspace-branding-upstream-4.11.1-6.8.i586[Tumbleweed_]
                   kdebase4-workspace-branding-upstream-4.11.1-6.8.x86_64[Tumbleweed_]
 Solution 1: Following actions will be done:
  downgrade of kdebase4-workspace-4.11.1-6.8.x86_64 to kdebase4-workspace-4.10.5-1.111.1.x86_64
  downgrade of kwin-4.11.1-6.8.x86_64 to kwin-4.10.5-1.111.1.x86_64
 Solution 2: deinstallation of kdebase4-workspace-branding-openSUSE-12.3-2.15.x86_64
 Solution 3: do not install patch:openSUSE-2013-584-1.noarch
 Solution 4: break kdebase4-workspace-4.11.1-6.8.x86_64 by ignoring some of its dependencies


Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c] (c): 

Please advise?!?

Please let us see your repos

zypper lr -d

Choose solution 3.
That patch is 12.3’s KDE update to 4.10.5, which of course is a downgrade in your case, as you already have 4.11.1.
Also you should not install that gtk2-branding-openSUSE (and downgrade libgtk-2_0-0 as a result), because that would lead to other problems.

You could then lock that patch (and maybe others) with “zypper al -t patch openSUSE-2013-584” (or right-click on it in YaST->Online Update and choose “Taboo”), so that zypper won’t try again to install it.

The best thing IMHO would be to change the priority of the Tumbleweed repo (and Packman if you use that) to 98, and just use “zypper dup” to update.
But this is my personal opinion and not in any way officially supported or endorsed. (this sentence is here to make consused happy…>:))

It will prevent those problems though and will also install security/bugfix updates from the update repo (contrary to “zypper dup --from Tumbleweed”).

#  | Alias                            | Name                             | Enabled | Refresh | Priority | Type   | URI                                                                                | Service
---+----------------------------------+----------------------------------+---------+---------+----------+--------+------------------------------------------------------------------------------------+--------
 1 | 'openSUSE_Current_OSS'           | 'openSUSE Current OSS'           | Yes     | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/openSUSE-current/repo/oss/               |        
 2 | 'openSUSE_Current_non-OSS'       | 'openSUSE Current non-OSS'       | Yes     | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/openSUSE-current/repo/non-oss/           |        
 3 | 'openSUSE_Current_updates'_      | 'openSUSE Current updates'       | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/update/openSUSE-current/                              |        
 4 | KDE:Extra                        | KDE:Extra                        | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed/          |        
 5 | Tumbleweed_                      | Tumbleweed                       | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/           |        
 6 | home:Strahlex                    | home:Strahlex                    | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/home:/Strahlex/openSUSE_Tumbleweed/      |        
 7 | home:geflei                      | home:geflei                      | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/home:/geflei/openSUSE_Tumbleweed/        |        
 8 | home:lnt-sysadmin:tools          | home:lnt-sysadmin:tools          | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/home:/lnt-sysadmin:/tools/openSUSE_12.3/ |        
 9 | home:oddball33                   | home:oddball33                   | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/home:/oddball33/openSUSE_Tumbleweed/     |        
10 | libdvdcss repository             | libdvdcss repository             | Yes     | Yes     |   99     | rpm-md | http://opensuse-guide.org/repo/12.3/                                               |        
11 | openSUSE_Current_non-OSS-Updates | openSUSE_Current_non-OSS-Updates | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/update/openSUSE-non-oss-current/                      |        
12 | packman                          | packman                          | Yes     | Yes     |   99     | rpm-md | http://packman.inode.at/suse/openSUSE_Tumbleweed                                   |

After option III, I then get this mess;

Problem: gtk2-branding-openSUSE-12.2-4.4.1.noarch requires libgtk-2_0-0 = 2.24.18, but this requirement cannot be provided
  uninstallable providers: libgtk-2_0-0-2.24.18-2.4.2.i586'openSUSE_Current_updates'_]
                   libgtk-2_0-0-2.24.18-2.4.2.x86_64'openSUSE_Current_updates'_]
 Solution 1: Following actions will be done:
  downgrade of libgtk-2_0-0-2.24.20-4.4.x86_64 to libgtk-2_0-0-2.24.18-2.4.2.x86_64
  downgrade of gtk2-immodule-vietnamese-2.24.20-4.4.x86_64 to gtk2-immodule-vietnamese-2.24.18-2.4.2.x86_64
  downgrade of gtk2-immodule-thai-2.24.20-4.4.x86_64 to gtk2-immodule-thai-2.24.18-2.4.2.x86_64
  downgrade of gtk2-immodule-inuktitut-2.24.20-4.4.x86_64 to gtk2-immodule-inuktitut-2.24.18-2.4.2.x86_64
  downgrade of gtk2-immodule-amharic-2.24.20-4.4.x86_64 to gtk2-immodule-amharic-2.24.18-2.4.2.x86_64
 Solution 2: deinstallation of gtk2-branding-openSUSE-12.2-2.4.noarch
 Solution 3: do not install patch:openSUSE-2013-436-1.noarch
 Solution 4: do not install patch:openSUSE-2013-436-1.noarch
 Solution 5: break gtk2-branding-openSUSE-12.2-4.4.1.noarch by ignoring some of its dependencies


Choose from above solutions by number or skip, retry or cancel [1/2/3/4/5/s/r/c] (c): 



And it just spirals.

Is tumbleweed even compatible with official patches from the update repository? I would think versions of programs would quickly surpass them.

AFAIK the process for keeping Tumbleweed updated is
zypper dup

I don’t even run zypper patch on my standard installs, because it can create similar issues once you have repos above and beyond the default.

I concur. That’s how I have been using Tumbleweed, and it has avoided dependency problems. Well, I think there was one dependency problem that went away by itself the next day.

LOL.

OK, so “zypper patch” is not really practicable because it wants to install all the patches (which means downgrading the corresponding packages because of dependencies).

Try “zypper up” then instead, this should only try to update those packages that need to be updated.

Not all updates in the update repo are available as newer version in the Tumbleweed repo because there’s no need to. Firefox and glibc are examples for packages that are not in Tumbleweed, but have updates in the update repo.

By just doing “zypper dup --from Tumbleweed” you would miss those.

With “zypper dup” they do get installed of course.

Likewise here.

Only someone who hasn’t used Tumbleweed would suggest to use zypper patch on it. lol!

I knew you would reply… :wink:

To be honest, I don’t use “zypper patch” on 12.3 either, because of those problems with KDE 4.11 f.e., which I do have installed (from [noparse]KDE:Distro:Factory[/noparse])

I admit “zypper patch” was a bad idea, I should have suggested “zypper up” right from the start. Well, I actually did in the reply to fleamor’s question in his other thread, but I should have left out the “zypper patch” part (that was a mistake, sorry! :shame:):

How do you know it has avoided asnything, if you haven’t had any problems? A negative cannot be proved, blah blah. Anymore than I can prove that a higher priority on Packman prevents problems that might occur without it, having tried both ways on Packman without issue. However with Packman, one might well wish to ensure that all multimedia packages are installed exclusively from its repo. That just isn’t the case for Tumbleweed repo according to the guy who tests it his way before releasing it.

For much of Tumbleweed based on 12.1, I used YaST to update it but wouldn’t recommend it to anyone else. lol!

You still can’t stop, can you?
People had problems and are having problems, just look at the posts in this forum.

Good for you if you don’t have any. But that is no prove either.

You can keep on sticking your head in the sand if you like, but please refrain from attacking people who try to help others with those problems.

Anyway, that situation should be resolved in a month or two, when Tumbleweed switches to 13.1 as base. Then no priority change should be necessary anymore (except for Packman maybe, if one wishes to).

[quote="“wolfi323,post:14,topic:94047”]

You still can’t stop, can you?
People had problems and are having problems, just look at the posts in this forum.

Good for you if you don’t have any. But that is no prove either.

You can keep on sticking your head in the sand if you like, but please refrain from attacking people who try to help others with those problems.[/QUOTE]
No need to get emotional and confuse contradiction with attack. It doesn’t actually answer the question I put, and by selective quoting you missed out the next sentence where I stated my example wrt Packman cannot prove it either, see here:

I hope that makes it clearer now. :slight_smile:

Well, sorry, I really did try to not get emotional this time.
But that’s the impression I got from your posts (especially in other threads, I did consider some of your posts as direct attack against me).

It doesn’t actually answer the question I put, and by selective quoting you missed out the next sentence where I stated my example wrt Packman cannot prove it either, see here:

What was your question? This one?

That I did answer, didn’t I?

For reference, this was meant as answer to that question:

I did selective quoting to make it clear to what I am answering to. My mention of Packman was not meant directly as reply to you, I mentioned that for completeness (ok, it was inspired by your post).

Frankly, no.

& plain ol’ zypper dup’ll be OK with my repos? Looks like patch switch is bad advice, still that is what image backup is for. Proper broke my system! Haha, still we learn…

rotfl!

Why?
Because I didn’t answer in the way you expected it? Sorry for that.

Right. Meanwhile I had a look at your repos, and you should be safe with “zypper dup” as well… :wink: