it tries to uninstall python3-base and then complains, that packages that depend on python(abi) = 3.6 (which is part of the python3-base package) have unmet dependencies. When I try to tell zypper to keep obsolete (which is AFAIK the least destructive option) on all the conflicts, more and more conflicts are spawned.
Output of zypper dup:
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...
6 Problems:
Problem: python3-protobuf-3.6.1-82.2.x86_64 requires python(abi) = 3.6, but this requirement cannot be provided
Problem: FreeCAD-0.17.1534399137.9948ee4f1-1.5.x86_64 requires libpyside2.cpython-36m-x86_64-linux-gnu.so.5.12()(64bit), but this requirement cannot be provided
Problem: rubygem-lolcat-42.1.44-3.18.x86_64 requires rubygem(ruby:2.5.0:trollop:2.1) >= 2.1.2, but this requirement cannot be provided
Problem: python3-wxPython-4.0.1-2.3.x86_64 requires python(abi) = 3.6, but this requirement cannot be provided
Problem: python3-pivy-0.6.4-1.1.x86_64 requires python(abi) = 3.6, but this requirement cannot be provided
Problem: python3-gdata-2.0.18-53.16.noarch requires python(abi) = 3.6, but this requirement cannot be provided
Problem: python3-protobuf-3.6.1-82.2.x86_64 requires python(abi) = 3.6, but this requirement cannot be provided
deleted providers: python3-base-3.6.5-3.3.x86_64
Solution 1: install python3-protobuf-3.6.1-2.3.x86_64 (with vendor change)
obs://build.opensuse.org/devel:tools --> openSUSE
Solution 2: keep obsolete python3-base-3.6.5-3.3.x86_64
Solution 3: break python3-protobuf-3.6.1-82.2.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): 2
Problem: FreeCAD-0.17.1534399137.9948ee4f1-1.5.x86_64 requires libpyside2.cpython-36m-x86_64-linux-gnu.so.5.12()(64bit), but this requirement cannot be provided
deleted providers: python3-pyside2-5.12.0-1.1.x86_64
Solution 1: deinstallation of FreeCAD-0.17.1534399137.9948ee4f1-1.5.x86_64
Solution 2: keep obsolete python3-pyside2-5.12.0-1.1.x86_64
Solution 3: break FreeCAD-0.17.1534399137.9948ee4f1-1.5.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): 2
Problem: rubygem-lolcat-42.1.44-3.18.x86_64 requires rubygem(ruby:2.5.0:trollop:2.1) >= 2.1.2, but this requirement cannot be provided
deleted providers: ruby2.5-rubygem-trollop-2.1.3-1.1.x86_64
Solution 1: deinstallation of rubygem-lolcat-42.1.44-3.18.x86_64
Solution 2: keep obsolete ruby2.5-rubygem-trollop-2.1.3-1.1.x86_64
Solution 3: break rubygem-lolcat-42.1.44-3.18.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): 2
Problem: python3-wxPython-4.0.1-2.3.x86_64 requires python(abi) = 3.6, but this requirement cannot be provided
deleted providers: python3-base-3.6.5-3.3.x86_64
Solution 1: deinstallation of aws-cli-1.16.61-1.1.noarch
Solution 2: deinstallation of python3-wxPython-4.0.1-2.3.x86_64
Solution 3: keep obsolete aws-cli-1.16.61-1.1.noarch
Solution 4: break python3-wxPython-4.0.1-2.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): 3
Problem: python3-pivy-0.6.4-1.1.x86_64 requires python(abi) = 3.6, but this requirement cannot be provided
deleted providers: python3-base-3.6.5-3.3.x86_64
Solution 1: deinstallation of criu-3.11-1.1.x86_64
Solution 2: deinstallation of python3-pivy-0.6.4-1.1.x86_64
Solution 3: keep obsolete criu-3.11-1.1.x86_64
Solution 4: break python3-pivy-0.6.4-1.1.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): 3
Problem: python3-gdata-2.0.18-53.16.noarch requires python(abi) = 3.6, but this requirement cannot be provided
deleted providers: python3-base-3.6.5-3.3.x86_64
Solution 1: Following actions will be done:
keep obsolete hplip-3.18.6-1.2.x86_64
keep obsolete hplip-hpijs-3.18.6-1.2.x86_64
keep obsolete hplip-sane-3.18.6-1.2.x86_64
Solution 2: deinstallation of hplip-3.18.6-1.2.x86_64
Solution 3: deinstallation of python3-gdata-2.0.18-53.16.noarch
Solution 4: break python3-gdata-2.0.18-53.16.noarch 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): 1
Resolving dependencies...
Computing distribution upgrade...
11 Problems:
Problem: byobu-5.127-15.2.noarch requires python3-newt, but this requirement cannot be provided
Problem: aws-cli-1.16.61-1.1.noarch requires python(abi) = 3.6, but this requirement cannot be provided
Problem: criu-3.11-1.1.x86_64 requires python(abi) = 3.6, but this requirement cannot be provided
Problem: hplip-3.18.6-1.2.x86_64 requires python(abi) = 3.6, but this requirement cannot be provided
Problem: python3-pyside2-5.12.0-1.1.x86_64 requires python(abi) = 3.6, but this requirement cannot be provided
Problem: python3-wheel-0.32.3-1.2.noarch requires python(abi) = 3.7, but this requirement cannot be provided
Problem: hplip-3.18.6-1.2.x86_64 requires python(abi) = 3.6, but this requirement cannot be provided
Problem: python3-wxPython-4.0.1-2.3.x86_64 requires python(abi) = 3.6, but this requirement cannot be provided
Problem: python3-pivy-0.6.4-1.1.x86_64 requires python(abi) = 3.6, but this requirement cannot be provided
Problem: python3-gdata-2.0.18-53.16.noarch requires python(abi) = 3.6, but this requirement cannot be provided
Problem: python3-pyside2-5.12.0-1.1.x86_64 requires python(abi) = 3.6, but this requirement cannot be provided
Problem: byobu-5.127-15.2.noarch requires python3-newt, but this requirement cannot be provided
not installable providers: python3-newt-0.52.20-5.5.i586[http-download.opensuse.org-10f09344]
python3-newt-0.52.20-5.5.x86_64[http-download.opensuse.org-10f09344]
python3-newt-0.52.20-5.5.i586[repo-oss]
python3-newt-0.52.20-5.5.x86_64[repo-oss]
Solution 1: deinstallation of byobu-5.127-12.3.noarch
Solution 2: keep obsolete byobu-5.127-12.3.noarch
Solution 3: remove lock to allow removal of python3-base-3.6.5-3.3.x86_64
Solution 4: break byobu-5.127-15.2.noarch 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): c
Hi
Well with all those home repositories, very likely that some packages present require rebuilding/fixing especially if python based as this last update was a big one. Home repositories are of low priority as well, so you would need to inspect each of those home projects to see what apps you have installed and the status of those packages.
For repo 39, your at the whim of the third party as to whether or not it gets fixed, updated if that’s required.
So, why all the additional repositories? If there are packages present especially in home repositories, ask the maintainer/packager to push to a development project and get forwarded to factory and then into Tumbleweed?
and the output was very similar. From that I concluded, that the problem must be in the oss repository, but I’m probably wrong.
There is so much repos, because when I don’t find a package I want to use in the repositories, I just use software.opensuse.com/search to find it and then use 1-click installation to install the packages. How does one do this correctly?
I doubt that at least some packages aren’t available from the TW repos, f.e. Go. The home: repos are packager’s home repos. That’s supposed to be the place where they can break things, test new versions etc. What happened now is that TW itself has moved to python3.7, where lots of those home: packages still require python3.6 . That is what you’re seeing. Even disabling all these repos and running ‘zypper dup --from …’ would leave a lot of unresolvable deps IMHO. To be honest, I’d seriously consider a reinstall, that might be a lot quicker and safer.
Hi
You would need to wait for all the fixes and rebuilds to propagate which could be some time, that’s your call…
So, if package X is in a home repository and not in a development repository, then you would need to ask that user to push to a development project and they request to be a maintainer (This is the first step), once accepted into the development project, then is can be pushed to factory (this is the second step), from there it will propagate into Tumbleweed after the necessary reviews, testing etc.
Hi
Well short of downloading the src rpm and rebuilding locally, there is not a lot that can be done. Even if you used OBS and linkpac’d all the packages, you still need to wait for the higher priority projects to rebuild (devel:languages: python[2,3] is ginormous) , or download and rebuild locally, but then you get into dependency issues if it’s needed by another. Like I indicated, either get packages pushed or wait…
Review what your using as some may be in Tumbleweed now, what are you getting from the non home projects (excluding third party ones)?
Sorry for not replying for quite a while, other things got in the way.
I actually managed to solve this by uninstalling all the packages that depend on python(abi) = 3.6, ignore broken dependencies and manually resolve them after the upgrade.
Regarding your question about running multiple Python, yes it’s possible to support multiple python versions side by side on a system and because it’s a common issue for Python developers (versions change often which break custom pyton apps), the standard utility used is virtualenv. And since you chose to install Tumbleweed, changes will happen a lot more often than if you had installed LEAP… some changes might break things although hopefully most won’t.
I haven’t run multiple pythons on an openSUSE lately, but awhile back whenever you installed a non-default python from the OSS, the new python would be installed with virtualenv automatically instead of upgrading the existing python. I don’t know if that still happens or not. Of course, that won’t likely help you if the system python updates to a new version but it’s something to keep in mind if you install a lot of custom python apps (eg from home repos).
Now that you have experienced python versioning problems related to what you do, you should consider your options moving forward…
Avoid custom python apps. Not always possible because python is extremely popular.
Use Virtualization (or isolation like LXC or docker) to run your python app in its own custom environment. If you’re not chasing that last approx 2% performance or don’t need direct hardware access (without lots of work), this is an easy option. This has been my preferred option for more reasons than just library versions.
Deploy virtualenv or some other python manager. This is the traditional solution, will require a little learning but is not hard to set up and use. It’s also the solution that uses the least amount of extra space.
Thank you very much for your long answer!
As I said, I solved the problem just by uninstalling the packages, that still depend on the old python, which luckily wasn’t that much of a problem, because there wasn’t so many of them.
In the future, I’ll definitely consider your advice, as I’ve worked with both docker and virtualenv in the past, but not in this context.