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):
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”).
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):
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.
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.
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).
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:
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).
& 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…
