>
> Problem: nothing provides rubygem(parseconfig) needed by
> ruby-CDApplet-3.4.0-1.1.i586
> Solution 1: Following actions will be done:
> keep obsolete ruby-CDApplet-3.3.2-1.23.x86_64
> keep obsolete python-CDBashApplet-3.3.2-1.23.noarch
> keep obsolete cairo-dock-plugins-dbus-interface-bash-3.3.2-1.23.noarch
> keep obsolete cairo-dock-plugins-dbus-interface-mono-3.3.2-1.23.noarch
> keep obsolete cairo-dock-plugins-dbus-3.3.2-1.23.x86_64
> keep obsolete cairo-dock-plugins-3.3.2-1.23.x86_64
> keep obsolete cairo-dock-3.3.2-3.116.x86_64
> keep obsolete libgldi3-3.3.2-3.116.x86_64
> Solution 2: break ruby-CDApplet-3.4.0-1.1.i586 by ignoring some of its
> dependencies
>
>
> Choose from above solutions by number or cancel [1/2/c] (c):
>
> Anyone experience the above, seems to be a never ending circle!
>
>
I had a similar experience a few months ago when testing 13.2-M*. There
was no solution to the problem so I just did nothing. Next day, I
went back to YaST and tried another update and the problem was no longer
there. I can only assume I caught the repos in a bad state and they got
sorted soon afterwards.
–
Graham Davis [Retired Fortran programmer - now a mere computer user]
openSUSE Tumbleweed (64-bit); KDE 4.14.3; AMD Phenom II X2 550
Processor; Kernel: 3.17.2; Video: nVidia GeForce 210 (using nVidia
driver); Sound: ATI SBx00 Azalia (Intel HDA)
KDE Extra is the only none Factory repo, but hey, Tumblweed is Factory now, right? Factory repo went down so figured would add Tw one. I can make a clean break in two moves by ignoring dependency for ruby applet.
I apologise for complete shambles. I did think as long as it a Factory repo it would be just fine. I add repos in order to gain the odd app unavailable elsewhere. However breakage seems to result. A learning curve for sure but any basic housekeeping tips accepted.
The Factory distribution is now Tumbleweed & no longer “Harlequin” as of now. That’s how I understand it.
Well, you might want to chat with or wait for comments from Factory/TW users, but the repos are separate. But perhaps Factory provides for TW and TW repos are merely a mirror of Factory.
But when seeking additional repos outside the original base repos you should exercise even more caution than a regular stable user
Packman for instance has a TW repo and Factory repo http://packman.inode.at/suse/openSUSE_Tumbleweed/
I’d suggest a return to the base set for either Factory or TW and do
zypper dup
Then progress gingerly with any additions
To me there is a lack of clarity because you are correct in what you say. But should you use Factory repos or TW repos
You see this comment is having me think:
‘Tumbleweed’ and ‘Factory’ rolling releases will be merging, and offered as a single openSUSE rolling release under the name ‘Tumbleweed’
Myself, looking at the info/wiki doesn’t make it much clearer.
Right. AIUI the temporary linking of the repos allows previous users of Factory to continue without main repo changes. By April/May 2015 they will have had to change them over to the Tumbleweed URL’s. The Factory repos will then disappear.
Some Tumbleweeders switched to newly improved Factory once it was promoted on the Factory ML (yes it still exists), and there Greg K-H also stated his intention to end his Tumbleweed service after 13.2 became available. Not everyone “jumped the gun”, and a wiser man on the ML pointed out that going forward with “new Factory” just sent out the wrong message! The announcement re new Tumbleweed duly followed.
A recent discussion on Factory ML has questioned the use of “zypper dup” for every single use case, such as those who need to pick 'n mix various packages from several/many “additional repos” that they wish to retain after upgrade/update. Various solutions involving repo priorities, package locks, use of “zypper up”. etc. were aired, but they can become over complicated. These are only for users who know exactly what they are doing, and who are able to reach a working system on their own! I believe “zypper dup” remains the generally recommended and supported method.
