After adding these two repos:
http://download.opensuse.org/repositories/KDE:/Distro:/Factory/openSUSE_Factory/
http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Factory/
I ran the command: “zypper dup --from KDE413” (KDE413 is what I named one of the two repos), and got 105 problems, such as: “Problem: nothing provides libexiv2.so.13 needed by strigi-0.7.8-91.23.i586”. Am I doing something wrong?
Those are the “Factory” repos holding the (in-work) KDE for the NEXT version (13.2) of openSUSE.
Do not use those repos with 13.1 - many conflicts will occur - and breakage.
That is not correct.
Any repo that has factory in the name should be considered unstable
stay away from the Factory repos.
There is now a unified KDE repo that will receive the latest update for openSUSE 13.1 when it is ready
http://download.opensuse.org/repositories/KDE:/Current/openSUSE_13.1/
I’m expecting there will be very little difference between KDE 4.12 and 4.13 as the major focus is now on KDE Frameworks 5
I was going by the email I got from the openSUSE mailing list which said KDE 4.13 was for the most part finalized, and the packages will stay in the Factory repo for a couple of weeks to make sure there are no major issues before moving the packages to the Current repo. I was under the impression that I could use the “dup” option in zypper without getting a bunch of errors.
Factory repo is for . . .
Factory and Project repositories When you encounter a bug in an openSUSE package and you cannot wait for your problem to be solved, there is a good chance that the bug does not appear in a recent version, either because it has been explicitly fixed or because it disappeared by itself. In order to test for this, you can try “bleeding edge” packages built by project developers. In order to get at the most recent version, go to the Software Portal and install the package with the most recent version number.
Warning Those packages are unsupported and may introduce further bugs that may corrupt or destroy your data, so use caution and back up often!
Scheduled 25 Apr on the Kde:Current repo:
http://lists.opensuse.org/opensuse-kde/2014-04/msg00105.html
Those URLs are for openSUSE Factory, but you are running 13.1. That’s why you get conflicts/missing dependencies.
Use the URLs for 13.1 instead:
http://download.opensuse.org/repositories/KDE:/Distro:/Factory/openSUSE_13.1
http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_13.1_KDE_Distro_Factory/
But please note, that KDE:Distro:Factory will be removed for 13.1 as soon as KDE 4.13 is available in KDE:Current.
So you will have to change the repos again in about a week.
So you might as well just add KDE:Current and KDE:Extra for KDE:Current, and wait another week for 4.13 to appear there.
I added those repos yesterday, but the packages hadn’t been updated yet. Now they are, but I am still getting errors in zypper when running “dup”.
linux-04hg:/home/pirithous # zypper dup --from KDE413
Retrieving repository 'Packman Repository' metadata .....................................................[done]
Building repository 'Packman Repository' cache ..........................................................[done]
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
3 Problems:
Problem: python-kde4-soprano-4.11.5-304.3.x86_64 requires python-kde4 = 4.11.5, but this requirement cannot be provided
Problem: NetworkManager-kde4-libs-lang-0.9.0.10-2.8.1.noarch requires NetworkManager-kde4-libs = 0.9.0.10, but this requirement cannot be provided
Problem: python-kde4-nepomuk-4.11.5-304.3.x86_64 requires libnepomuk.so.4()(64bit), but this requirement cannot be provided
Problem: python-kde4-soprano-4.11.5-304.3.x86_64 requires python-kde4 = 4.11.5, but this requirement cannot be provided
Solution 1: deinstallation of python-kde4-soprano-4.11.5-304.3.x86_64
Solution 2: keep obsolete python-kde4-4.11.5-304.3.x86_64
Solution 3: keep obsolete python-kde4-4.11.5-304.3.x86_64
Solution 4: break python-kde4-soprano-4.11.5-304.3.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):
Uninstall python-kde4-soprano that doesn’t exist anymore.
The new baloo (replacement for nepomuk) does not use soprano.
And python-kde4-soprano was only there to access soprano from python scripts, so you likely don’t/didn’t need it anyway.
PS: The same is true for python-kde4-nepomuk, this doesn’t exist anymore because nepomuk has been replaced by baloo.
And NetworkManager-kde4-lang you can uninstall as well.
But I don’t understand why you cannot wait another week for 4.13 (and/or use 4.12.4 in the meantime), when you still have 4.11.5 installed. 
Okay, thanks for the info. Does 4.12.4 exist in the Current repo? I thought I added that already and nothing happened. How about this issue? I see no uninstall option.
Problem: python-kde4-nepomuk-4.11.5-304.3.x86_64 requires libnepomuk.so.4()(64bit), but this requirement cannot be provided
uninstallable providers: libkde4-4.11.2-3.1.x86_64[repo-oss]
libkde4-4.11.3-52.3.x86_64[repo-update]
libkde4-4.11.4-464.8.x86_64[repo-update]
Solution 1: Following actions will be done:
architecture change of python-kde4-nepomuk-4.11.5-304.3.x86_64 to python-kde4-nepomuk-4.11.5-304.3.i586
install python-kde4-nepomuk-4.11.5-304.3.i586 despite the inferior architecture
Solution 2: keep obsolete libkde4-4.11.5-480.3.x86_64
Solution 3: break python-kde4-nepomuk-4.11.5-304.3.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or skip, retry or cancel [1/2/3/s/r/c] (c):
I mean NetworkManager-kde4-libs-lang of course.
The new plasma-nm does not use NetworkManager-kde4-libs anymore, that’s why it got removed as well.
It uses libNetworkManagerQt0 now.
Of course, since its inception.
How about this issue? I see no uninstall option.
Hm, no idea why zypper doesn’t show one.
I would suggest to uninstall it manually then before upgrading, either in YaST or with:
sudo rpm -e python-kde4-nepomuk
Or tell zypper to break it by ignoring the dependency, then uninstall it later.
Okay, excellent. It’s going right now. I used the “rpm -e” option to uninstall that python package; I don’t know why zypper didn’t give the option to uninstall it either.