New Tumbleweed snapshot 20230813 installs python 3.10 again
Hi, current TW snapshot seems to be a large one again. Strange enough, I had python 3.10 removed from my system weeks ago, and now the latest snapshot wants to install this again. Any indication why? Thx Axel
* Axel Braun <docb@opensuse.org> [08-14-23 16:02]:
Hi, current TW snapshot seems to be a large one again. Strange enough, I had python 3.10 removed from my system weeks ago, and now the latest snapshot wants to install this again. Any indication why?
perhaps something particular to your installation. did not happen on my 7 boxes. but it was a large upgrade. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Am Montag, 14. August 2023, 21:05:11 BST schrieb Patrick Shanahan:
* Axel Braun <docb@opensuse.org> [08-14-23 16:02]:
Hi, current TW snapshot seems to be a large one again. Strange enough, I had python 3.10 removed from my system weeks ago, and now the latest snapshot wants to install this again. Any indication why?
perhaps something particular to your installation. did not happen on my 7 boxes. but it was a large upgrade.
Any existing dependency should have come up in an earlier dup already, which is not the case. So it seems to be a new depedency.... Cheers Axel
On Monday 2023-08-14 22:16, Axel Braun wrote:
Am Montag, 14. August 2023, 21:05:11 BST schrieb Patrick Shanahan:
* Axel Braun <docb@opensuse.org> [08-14-23 16:02]:
Hi, current TW snapshot seems to be a large one again. Strange enough, I had python 3.10 removed from my system weeks ago, and now the latest snapshot wants to install this again. Any indication why?
perhaps something particular to your installation. did not happen on my 7 boxes. but it was a large upgrade.
Any existing dependency should have come up in an earlier dup already, which is not the case. So it seems to be a new depedency....
zypper al python310-base zypper dup zypper rl python310-base zypper dup see what gets upgraded, that'll be the culprit
Am Montag, 14. August 2023, 21:28:41 BST schrieb Jan Engelhardt:
On Monday 2023-08-14 22:16, Axel Braun wrote:
Am Montag, 14. August 2023, 21:05:11 BST schrieb Patrick Shanahan:
Any existing dependency should have come up in an earlier dup already, which is not the case. So it seems to be a new depedency....
zypper al python310-base zypper dup zypper rl python310-base zypper dup
see what gets upgraded, that'll be the culprit
No python 310 installed: *X1E:/home/docb #* english zypper se -i python310 Loading repository data... Reading installed packages... No matching items found. Cheers Axel
In my case it wiped out internet access. Wired connection will not work. Fortunately wi-fi still connects. On Mon, Aug 14, 2023 at 1:05 PM Patrick Shanahan <paka@opensuse.org> wrote:
* Axel Braun <docb@opensuse.org> [08-14-23 16:02]:
Hi, current TW snapshot seems to be a large one again. Strange enough, I had python 3.10 removed from my system weeks ago, and now the latest snapshot wants to install this again. Any indication why?
perhaps something particular to your installation. did not happen on my 7 boxes. but it was a large upgrade.
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Chuck Davis composed on 2023-08-14 13:19 (UTC-0700):
In my case it wiped out internet access. Wired connection will not work. Fortunately wi-fi still connects.
Did your wired connection use Wicked? Was Wicked removed? Mine all use systemd-networkd. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
No, I'm using NetworkManager. I'm home from work now so will be attempting to get my connection back. On Mon, Aug 14, 2023 at 2:25 PM Felix Miata <mrmazda@earthlink.net> wrote:
Chuck Davis composed on 2023-08-14 13:19 (UTC-0700):
In my case it wiped out internet access. Wired connection will not work. Fortunately wi-fi still connects.
Did your wired connection use Wicked? Was Wicked removed? Mine all use systemd-networkd. -- Evolution as taught in public schools is, like religion, based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
* Felix Miata <mrmazda@earthlink.net> [08-14-23 17:26]:
Chuck Davis composed on 2023-08-14 13:19 (UTC-0700):
In my case it wiped out internet access. Wired connection will not work. Fortunately wi-fi still connects.
Did your wired connection use Wicked? Was Wicked removed? Mine all use systemd-networkd.
NetworkManager and do not have systemd-network installed. there doesn't seem to be a systemd-networkd. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 8/14/23 19:26, Patrick Shanahan wrote:
* Felix Miata <mrmazda@earthlink.net> [08-14-23 17:26]:
Chuck Davis composed on 2023-08-14 13:19 (UTC-0700):
In my case it wiped out internet access. Wired connection will not work. Fortunately wi-fi still connects. Did your wired connection use Wicked? Was Wicked removed? Mine all use systemd-networkd. NetworkManager and do not have systemd-network installed. there doesn't seem to be a systemd-networkd.
Hi Patrick, The package in TW is systemd-network but the services are systemd-networkd and systemd-resolved -- Regards, Joe
Patrick Shanahan composed on 2023-08-14 19:26 (UTC-0400):
* Felix Miata composed:
Did your wired connection use Wicked? Was Wicked removed? Mine all use systemd-networkd.
NetworkManager and do not have systemd-network installed. there doesn't seem to be a systemd-networkd.
Package management calls it systemd-network. It used to not be a separate package. Systemctl calls it/them: # systemctl list-unit-files | grep temd-net systemd-network-generator.service disabled enabled systemd-networkd-wait-online.service disabled disabled systemd-networkd-wait-online@.service disabled disabled systemd-networkd.service disabled disabled systemd-networkd.socket enabled disabled # -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Yeah, happened on my machine too. NetworkManager also reported that I still have a connection and I also got a new IP when reconnecting the cable. But well, a reboot fixed it. Am 14.08.23 um 22:19 schrieb Chuck Davis:
In my case it wiped out internet access. Wired connection will not work. Fortunately wi-fi still connects.
On Mon, Aug 14, 2023 at 1:05 PM Patrick Shanahan <paka@opensuse.org <mailto:paka@opensuse.org>> wrote:
* Axel Braun <docb@opensuse.org <mailto:docb@opensuse.org>> [08-14-23 16:02]: > Hi, > current TW snapshot seems to be a large one again. > Strange enough, I had python 3.10 removed from my system weeks ago, and now the latest snapshot wants to install this again. > Any indication why?
perhaps something particular to your installation. did not happen on my 7 boxes. but it was a large upgrade.
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org <http://en.opensuse.org> openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo <http://wahoo.no-ip.org/piwigo> paka @ IRCnet oftc
Sincerely Kilian Hanich
* Chuck Davis <cjgunzel@gmail.com> [08-14-23 16:20]:
In my case it wiped out internet access. Wired connection will not work. Fortunately wi-fi still connects.
On Mon, Aug 14, 2023 at 1:05 PM Patrick Shanahan <paka@opensuse.org> wrote:
* Axel Braun <docb@opensuse.org> [08-14-23 16:02]:
Hi, current TW snapshot seems to be a large one again. Strange enough, I had python 3.10 removed from my system weeks ago, and now the latest snapshot wants to install this again. Any indication why?
perhaps something particular to your installation. did not happen on my 7 boxes. but it was a large upgrade.
I too, lost wired internet and could not regain w/o rebooting, but didn't really try too hard. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Hi, Am Montag, 14. August 2023, 22:01:16 CEST schrieb Axel Braun:
Hi, current TW snapshot seems to be a large one again. Strange enough, I had python 3.10 removed from my system weeks ago, and now the latest snapshot wants to install this again. Any indication why?
Run (before python310-base got installed): zypper -v dup --debug-solver testsolv -W python310-base /var/log/zypper.solverTestCase/testcase.t Cheers, Fabian
Thx Axel
Hello Fabian, Am Dienstag, 15. August 2023, 08:57:49 BST schrieb Fabian Vogt:
Hi,
Am Montag, 14. August 2023, 22:01:16 CEST schrieb Axel Braun:
Hi, current TW snapshot seems to be a large one again. Strange enough, I had python 3.10 removed from my system weeks ago, and now the latest snapshot wants to install this again. Any indication why?
Run (before python310-base got installed):
zypper -v dup --debug-solver testsolv -W python310-base /var/log/zypper.solverTestCase/testcase.t
*X1E:/home/docb #* testsolv -W python310-base /var/log/zypper.solverTestCase/testcase.t installed python311-ipyparallel-8.6.1-1.4.noarch@repo-oss: python311-ipyparallel-8.6.1-1.3.noarch needs to stay installed or be updated installed jupyter-ipyparallel-8.6.1-1.4.noarch@repo-oss: python311-ipyparallel-8.6.1-1.4.noarch recommends jupyter-ipyparallel = 8.6.1 installed jupyter-jupyterlab-4.0.4-1.1.noarch@repo-oss: jupyter-ipyparallel-8.6.1-1.4.noarch requires jupyter-jupyterlab >= 3.6 installed python310-jupyterlab-4.0.4-1.1.noarch@repo-oss: jupyter-jupyterlab-4.0.4-1.1.noarch requires python3dist(jupyterlab) = 4.0.4 installed python310-base-3.10.12-3.2.x86_64@repo-oss: python310-jupyterlab-4.0.4-1.1.noarch requires python(abi) = 3.10 So this jupyter-stuff seems to be the bad guy: *X1E:/home/docb #* english zypper se -i jupyter Loading repository data... Reading installed packages... S | Name | Summary | Type ---+------------------------------------+----------------------------------------------------------------------------+-------- i | jupyter-jupyter_core-filesystem | Common directories shared by Jupyter packages | package i | jupyter-jupyterlab-filesystem | Common directories shared by JupyterLab packages | package i | jupyter-jupyterlab-pygments | Pygments theme for jupyterlab -- Jupyterlab extension files | package i | jupyter-jupyterlab-widgets | A JupyterLab extension for Jupyter/IPython widgets - Jupyter JS files | package i | jupyter-nbclassic | Jupyter Notebook as a Jupyter Server Extension | package i | jupyter-nbconvert | Conversion of Jupyter Notebooks | package i | jupyter-notebook | Jupyter Notebook interface | package i | jupyter-notebook-filesystem | Common directories shared by Jupyter notebook packages | package i | jupyter-notebook-shim | The configuration file for python-notebook-shim | package i | jupyter-server-terminals | Jupyter Server Extension registration for python*-jupyter-server-terminals | package i | jupyter-widgetsnbextension | Jupyter interactive widgets for Jupyter Notebook - Jupyter Files | package i | python311-jupyter | Metapackage to install all the Jupyter components in one go | package i | python311-jupyter-client7 | Jupyter protocol implementation and client libraries | package i | python311-jupyter-core | Base package on which Jupyter projects rely | package i+ | python311-jupyter-events | Jupyter Event System library | package i | python311-jupyter-server | The backend to Jupyter web applications | package i | python311-jupyter-server-terminals | A Jupyter Server Extension Providing Terminals | package i | python311-jupyter_console | Jupyter terminal console | package i | python311-jupyterlab-pygments | Pygments theme for jupyterlab | package i | python311-jupyterlab-widgets | A JupyterLab extension for Jupyter/IPython widgets | package Bugreport? Thanks Axel
On Aug 15 2023, Axel Braun wrote:
Hello Fabian,
Am Dienstag, 15. August 2023, 08:57:49 BST schrieb Fabian Vogt:
Hi,
Am Montag, 14. August 2023, 22:01:16 CEST schrieb Axel Braun:
Hi, current TW snapshot seems to be a large one again. Strange enough, I had python 3.10 removed from my system weeks ago, and now the latest snapshot wants to install this again. Any indication why?
Run (before python310-base got installed):
zypper -v dup --debug-solver testsolv -W python310-base /var/log/zypper.solverTestCase/testcase.t
*X1E:/home/docb #* testsolv -W python310-base /var/log/zypper.solverTestCase/testcase.t installed python311-ipyparallel-8.6.1-1.4.noarch@repo-oss: python311-ipyparallel-8.6.1-1.3.noarch needs to stay installed or be updated installed jupyter-ipyparallel-8.6.1-1.4.noarch@repo-oss: python311-ipyparallel-8.6.1-1.4.noarch recommends jupyter-ipyparallel = 8.6.1 installed jupyter-jupyterlab-4.0.4-1.1.noarch@repo-oss: jupyter-ipyparallel-8.6.1-1.4.noarch requires jupyter-jupyterlab >= 3.6 installed python310-jupyterlab-4.0.4-1.1.noarch@repo-oss: jupyter-jupyterlab-4.0.4-1.1.noarch requires python3dist(jupyterlab) = 4.0.4 installed python310-base-3.10.12-3.2.x86_64@repo-oss: python310-jupyterlab-4.0.4-1.1.noarch requires python(abi) = 3.10
So this jupyter-stuff seems to be the bad guy:
There are three packages providing python3dist(jupyterlab), and for some reason zypper selects python310-jupyterlab instead of python311-jupyterlab. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On Tue, Aug 15, 2023 at 11:50 AM Andreas Schwab <schwab@suse.de> wrote:
On Aug 15 2023, Axel Braun wrote:
Hello Fabian,
Am Dienstag, 15. August 2023, 08:57:49 BST schrieb Fabian Vogt:
Hi,
Am Montag, 14. August 2023, 22:01:16 CEST schrieb Axel Braun:
Hi, current TW snapshot seems to be a large one again. Strange enough, I had python 3.10 removed from my system weeks ago, and now the latest snapshot wants to install this again. Any indication why?
Run (before python310-base got installed):
zypper -v dup --debug-solver testsolv -W python310-base /var/log/zypper.solverTestCase/testcase.t
*X1E:/home/docb #* testsolv -W python310-base /var/log/zypper.solverTestCase/testcase.t installed python311-ipyparallel-8.6.1-1.4.noarch@repo-oss: python311-ipyparallel-8.6.1-1.3.noarch needs to stay installed or be updated installed jupyter-ipyparallel-8.6.1-1.4.noarch@repo-oss: python311-ipyparallel-8.6.1-1.4.noarch recommends jupyter-ipyparallel = 8.6.1 installed jupyter-jupyterlab-4.0.4-1.1.noarch@repo-oss: jupyter-ipyparallel-8.6.1-1.4.noarch requires jupyter-jupyterlab >= 3.6 installed python310-jupyterlab-4.0.4-1.1.noarch@repo-oss: jupyter-jupyterlab-4.0.4-1.1.noarch requires python3dist(jupyterlab) = 4.0.4 installed python310-base-3.10.12-3.2.x86_64@repo-oss: python310-jupyterlab-4.0.4-1.1.noarch requires python(abi) = 3.10
So this jupyter-stuff seems to be the bad guy:
There are three packages providing python3dist(jupyterlab), and for some reason zypper selects python310-jupyterlab instead of python311-jupyterlab.
But how can zypper decide which package is the correct one? Any choice will be random. Maybe a package requiring it can be changed to versioned requires? python3.11dist(jupyterlab) etc.
On Tue, 15 Aug 2023 11:59:20 +0300, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Tue, Aug 15, 2023 at 11:50 AM Andreas Schwab <schwab@suse.de> wrote:
On Aug 15 2023, Axel Braun wrote:
Am Dienstag, 15. August 2023, 08:57:49 BST schrieb Fabian Vogt:
Am Montag, 14. August 2023, 22:01:16 CEST schrieb Axel Braun:
Hi, current TW snapshot seems to be a large one again. Strange enough, I had python 3.10 removed from my system weeks ago, and now the latest snapshot wants to install this again. Any indication why?
Run (before python310-base got installed):
zypper -v dup --debug-solver testsolv -W python310-base /var/log/zypper.solverTestCase/testcase.t
*X1E:/home/docb #* testsolv -W python310-base /var/log/zypper.solverTestCase/testcase.t installed python311-ipyparallel-8.6.1-1.4.noarch@repo-oss: python311-ipyparallel-8.6.1-1.3.noarch needs to stay installed or be updated installed jupyter-ipyparallel-8.6.1-1.4.noarch@repo-oss: python311-ipyparallel-8.6.1-1.4.noarch recommends jupyter-ipyparallel = 8.6.1 installed jupyter-jupyterlab-4.0.4-1.1.noarch@repo-oss: jupyter-ipyparallel-8.6.1-1.4.noarch requires jupyter-jupyterlab >= 3.6 installed python310-jupyterlab-4.0.4-1.1.noarch@repo-oss: jupyter-jupyterlab-4.0.4-1.1.noarch requires python3dist(jupyterlab) = 4.0.4 installed python310-base-3.10.12-3.2.x86_64@repo-oss: python310-jupyterlab-4.0.4-1.1.noarch requires python(abi) = 3.10
So this jupyter-stuff seems to be the bad guy:
There are three packages providing python3dist(jupyterlab), and for some reason zypper selects python310-jupyterlab instead of python311-jupyterlab.
But how can zypper decide which package is the correct one? Any choice will be random.
That seems to be consistent with my results. I had never removed python 3.10, and so have those plus almost as many 3.11 packages. So I tried removing 3.10. Does this show that dependencies that pulled in python310 packages can be satisfied by python311 packages? (Tumbleweed 20230813): ----------------------------------------------------------------------- $ zypper --no-color in -D --solver-focus Installed -- -python310-base Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the installed python310-zstd-1.5.5.1-1.2.x86_64 requires 'python(abi) = 3.10', but this requirement cannot be provided Solution 1: Following actions will be done: deinstallation of python310-zstd-1.5.5.1-1.2.x86_64 deinstallation of python310-bcrypt-4.0.1-2.3.x86_64 [...] deinstallation of python310-Automat-22.10.0-2.3.noarch deinstallation of python310-3.10.12-3.1.x86_64 deinstallation of libpython3_10-1_0-3.10.12-3.2.x86_64 deinstallation of python310-dask-distributed-2023.5.1-2.3.noarch deinstallation of python310-Twisted-tls-22.10.0-7.2.noarch deinstallation of python310-jsonschema-format-nongpl-4.18.6-1.1.noarch deinstallation of python310-pandas-performance-2.0.2-4.2.noarch Solution 2: keep python310-base-3.10.12-3.2.x86_64 Solution 3: break python310-zstd-1.5.5.1-1.2.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): 1 Resolving dependencies... Resolving package dependencies... The following 12 NEW packages are going to be installed: python311-aiofiles python311-aiosqlite python311-async-lru python311-json5 python311-jupyter-collaboration python311-jupyter-lsp python311-jupyter-server-fileid python311-jupyter-ydoc python311-jupyterlab python311-jupyterlab-server python311-y-py python311-ypy-websocket The following 365 packages are going to be REMOVED: libpython3_10-1_0 python310 python310-Automat python310-Babel python310-Bottleneck python310-Brotli python310-CommonMark python310-Cycler [...] python310-jsonschema-format-nongpl python310-jsonschema-specifications python310-jupyter python310-jupyter-client7 python310-jupyter-collaboration python310-jupyter-core python310-jupyter-events python310-jupyter-lsp python310-jupyter-server python310-jupyter-server-fileid python310-jupyter-server-terminals python310-jupyter-ydoc python310-jupyter_console python310-jupyterlab python310-jupyterlab-pygments python310-jupyterlab-server python310-jupyterlab-widgets python310-kiwisolver python310-lazy-loader python310-linux-procfs python310-llvmlite [...] python310-zipp python310-zope.event python310-zope.interface python310-zopfli python310-zstd 12 new packages to install, 365 to remove. Overall download size: 5.2 MiB. Already cached: 0 B. After the operation, 954.8 MiB will be freed. Continue? [y/n/v/...? shows all options] (y): n $ -----------------------------------------------------------------------
Maybe a package requiring it can be changed to versioned requires? python3.11dist(jupyterlab) etc.
-- Robert Webb
On Tue, Aug 15, 2023 at 3:49 PM Robert Webb via openSUSE Factory <factory@lists.opensuse.org> wrote:
There are three packages providing python3dist(jupyterlab), and for some reason zypper selects python310-jupyterlab instead of python311-jupyterlab.
Alphanumeric sort (python310 < python311 < python39)?
But how can zypper decide which package is the correct one? Any choice will be random.
That seems to be consistent with my results. I had never removed python 3.10, and so have those plus almost as many 3.11 packages. So I tried removing 3.10. Does this show that dependencies that pulled in python310 packages can be satisfied by python311 packages? (Tumbleweed 20230813):
Sure. Looking at the build log, python-jupiterlab does not really "build" anything - it simply installs python scripts three times (for Python 3.9, 3.10 and 3.11). So they are really identical. The only version-dependent part is the cache of compiled python code (.pyc files). I do not know how common is this situation and have zero knowledge about python packaging, but assuming one can have common location for scripts themselves and per-version locations for pyc files this really calls for a) single package python3-jupiterlab which installs into something like /usr/lib/python3 b) per-version packages containing pyc files that install into /usr/lib/python311 etc and supplement python311-base etc and python3-jupyterlab. As said, no idea if this is doable.
Am Dienstag, 15. August 2023, 14:02:47 BST schrieb Andrei Borzenkov:
On Tue, Aug 15, 2023 at 3:49 PM Robert Webb via openSUSE Factory
....
I do not know how common is this situation and have zero knowledge about python packaging, but assuming one can have common location for scripts themselves and per-version locations for pyc files this really calls for
a) single package python3-jupiterlab which installs into something like /usr/lib/python3 b) per-version packages containing pyc files that install into /usr/lib/python311 etc and supplement python311-base etc and python3-jupyterlab.
I think that should be feasible. Added python-jupyterlab mainteners in bcc Cheers Axel
Hi, Am 16.08.23 um 02:04 schrieb Axel Braun:
Am Dienstag, 15. August 2023, 14:02:47 BST schrieb Andrei Borzenkov:
On Tue, Aug 15, 2023 at 3:49 PM Robert Webb via openSUSE Factory ....
I do not know how common is this situation and have zero knowledge about python packaging, but assuming one can have common location for scripts themselves and per-version locations for pyc files this really calls for
a) single package python3-jupiterlab which installs into something like /usr/lib/python3 b) per-version packages containing pyc files that install into /usr/lib/python311 etc and supplement python311-base etc and python3-jupyterlab. I think that should be feasible. Added python-jupyterlab mainteners in bcc
That is how Debian based distros do it. But the RPM world chose a different path. Specifically at openSUSE Tumbleweed we have single-spec multi-flavor python packages [1]. Changing it to the Debian way would be a major endeavour which I am sure nobody is eager to do. The jupyter-* packages without the pythonXXX- prefix are a different story alltogether.
Cheers Axel
Am 15.08.23 um 01:59 schrieb Andrei Borzenkov:
On Tue, Aug 15, 2023 at 11:50 AM Andreas Schwab <schwab@suse.de> wrote:
On Aug 15 2023, Axel Braun wrote:
Hello Fabian,
Hi,
Am Montag, 14. August 2023, 22:01:16 CEST schrieb Axel Braun:
Hi, current TW snapshot seems to be a large one again. Strange enough, I had python 3.10 removed from my system weeks ago, and now the latest snapshot wants to install this again. Any indication why? Run (before python310-base got installed):
zypper -v dup --debug-solver testsolv -W python310-base /var/log/zypper.solverTestCase/testcase.t *X1E:/home/docb #* testsolv -W python310-base /var/log/zypper.solverTestCase/testcase.t installed python311-ipyparallel-8.6.1-1.4.noarch@repo-oss:
Am Dienstag, 15. August 2023, 08:57:49 BST schrieb Fabian Vogt: python311-ipyparallel-8.6.1-1.3.noarch needs to stay installed or be updated installed jupyter-ipyparallel-8.6.1-1.4.noarch@repo-oss: python311-ipyparallel-8.6.1-1.4.noarch recommends jupyter-ipyparallel = 8.6.1 installed jupyter-jupyterlab-4.0.4-1.1.noarch@repo-oss: jupyter-ipyparallel-8.6.1-1.4.noarch requires jupyter-jupyterlab >= 3.6 installed python310-jupyterlab-4.0.4-1.1.noarch@repo-oss: jupyter-jupyterlab-4.0.4-1.1.noarch requires python3dist(jupyterlab) = 4.0.4 installed python310-base-3.10.12-3.2.x86_64@repo-oss: python310-jupyterlab-4.0.4-1.1.noarch requires python(abi) = 3.10
So this jupyter-stuff seems to be the bad guy: There are three packages providing python3dist(jupyterlab), and for some reason zypper selects python310-jupyterlab instead of python311-jupyterlab.
But how can zypper decide which package is the correct one? Any choice will be random.
The user has to do the selection by installing python3XX-jupyterlab. In 99% of all cases that is the primary python311 version automatically because the python311-jupyterlab package is selected through another dependency or already installed. I am surprised that previously clean installation pulls in python310-jupyterlab through this ambiguity. Suggestions to fix it without forcing python311 are welcome.
Maybe a package requiring it can be changed to versioned requires? python3.11dist(jupyterlab) etc.
The intention of python3dist() provided by all the flavor is, that the jupyter-juypterlab package works with ANY flavor. It keeps the possibility to only install a specific flavor which the user prefers to work in. Ben
On Wed, Aug 16, 2023 at 10:52 PM Ben Greiner <code@bnavigator.de> wrote:
There are three packages providing python3dist(jupyterlab), and for some reason zypper selects python310-jupyterlab instead of python311-jupyterlab.
But how can zypper decide which package is the correct one? Any choice will be random.
The user has to do the selection by installing python3XX-jupyterlab. In 99% of all cases that is the primary python311 version automatically because the python311-jupyterlab package is selected through another dependency or already installed. I am surprised that previously clean installation pulls in python310-jupyterlab through this ambiguity. Suggestions to fix it without forcing python311 are welcome.
RPM boolean dependencies? Requires: (python3.11dist(jupyterlab) if python3 == 3.11) Requires: (python3.10dist(jupyterlab) if python3 == 3.10) Requires: (python3.9dist(jupyterlab) if python3 == 3.9) The corner case is installation on a system without any python at all, as in this case nothing gets installed. It would be possible to add Requires: (python3 == 3.11 unless python3) where version is the current default or recommended version and will change when 3.11 is replaced with 3.12. https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.ht... P.S. I /hope/ zypper supports them ... :)
Maybe a package requiring it can be changed to versioned requires? python3.11dist(jupyterlab) etc.
The intention of python3dist() provided by all the flavor is, that the jupyter-juypterlab package works with ANY flavor. It keeps the possibility to only install a specific flavor which the user prefers to work in.
Ben
Am Donnerstag, 17. August 2023, 07:51:08 BST schrieb Andrei Borzenkov:
On Wed, Aug 16, 2023 at 10:52 PM Ben Greiner <code@bnavigator.de> wrote:
There are three packages providing python3dist(jupyterlab), and for some reason zypper selects python310-jupyterlab instead of python311-jupyterlab.
But how can zypper decide which package is the correct one? Any choice will be random.
The user has to do the selection by installing python3XX-jupyterlab. In 99% of all cases that is the primary python311 version automatically because the python311-jupyterlab package is selected through another dependency or already installed. I am surprised that previously clean installation pulls in python310-jupyterlab through this ambiguity. Suggestions to fix it without forcing python311 are welcome.
RPM boolean dependencies?
Requires: (python3.11dist(jupyterlab) if python3 == 3.11) Requires: (python3.10dist(jupyterlab) if python3 == 3.10) Requires: (python3.9dist(jupyterlab) if python3 == 3.9)
The corner case is installation on a system without any python at all, as in this case nothing gets installed. It would be possible to add
Requires: (python3 == 3.11 unless python3)
where version is the current default or recommended version and will change when 3.11 is replaced with 3.12.
https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.ht...
P.S. I /hope/ zypper supports them ... :)
I have opened a bug for it: https://bugzilla.opensuse.org/show_bug.cgi?id=1214354[1] In case anyone replies to this thread, please change the subject to the above ('New Tumbleweed' removed) - just learned that the original subject triggers a post into the openSUSE Forums.... Cheers Axel -------- [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1214354
Am 17.08.23 um 02:27 schrieb Axel Braun:
Am Donnerstag, 17. August 2023, 07:51:08 BST schrieb Andrei Borzenkov:
On Wed, Aug 16, 2023 at 10:52 PM Ben Greiner <code@bnavigator.de> wrote:
There are three packages providing python3dist(jupyterlab), and for some
reason zypper selects python310-jupyterlab instead of
python311-jupyterlab.
But how can zypper decide which package is the correct one? Any choice
will be random.
The user has to do the selection by installing python3XX-jupyterlab. In
99% of all cases that is the primary python311 version automatically
because the python311-jupyterlab package is selected through another
dependency or already installed. I am surprised that previously clean
installation pulls in python310-jupyterlab through this ambiguity.
Suggestions to fix it without forcing python311 are welcome.
RPM boolean dependencies?
Requires: (python3.11dist(jupyterlab) if python3 == 3.11)
Requires: (python3.10dist(jupyterlab) if python3 == 3.10)
Requires: (python3.9dist(jupyterlab) if python3 == 3.9)
The corner case is installation on a system without any python at all,
as in this case nothing gets installed. It would be possible to add
Requires: (python3 == 3.11 unless python3)
That's not how the python flavor nomenclature works.
where version is the current default or recommended version and will
change when 3.11 is replaced with 3.12.
https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.ht...
P.S. I /hope/ zypper supports them ... :)
Zypper in TW supports them, but your approach has a few shortcomings which makes it unsuitable in my eyes. * As you already mentioned, it would fail when not even one flavor is installed. * python3 == 3.1X would only work for 3.1X.0 versions. python31X-base without any version would be the correct name * This installs jupyterlab and all of its dependencies for all installed python flavors, regardless whether the user wants it really for all flavors or whether the other flavors are installed for different reasons. * Every time the flavor build set changes, all the jupyter-* packages, which have the same python3dist idiom for the same purpose would need to be updated. (Or a macro automatically expanding it to the flavors needs to be introduced)
I have opened a bug for it:
https://bugzilla.opensuse.org/show_bug.cgi?id=1214354
In case anyone replies to this thread, please change the subject to the above ('New Tumbleweed' removed) - just learned that the original subject triggers a post into the openSUSE Forums....
Cheers
Axel
- Ben
Am 17.08.23 um 11:54 schrieb Ben Greiner:
Am 17.08.23 um 02:27 schrieb Axel Braun:
Am Donnerstag, 17. August 2023, 07:51:08 BST schrieb Andrei Borzenkov:
On Wed, Aug 16, 2023 at 10:52 PM Ben Greiner <code@bnavigator.de> wrote:
There are three packages providing python3dist(jupyterlab), and for some
reason zypper selects python310-jupyterlab instead of
python311-jupyterlab.
But how can zypper decide which package is the correct one? Any choice
will be random.
The user has to do the selection by installing python3XX-jupyterlab. In
99% of all cases that is the primary python311 version automatically
because the python311-jupyterlab package is selected through another
dependency or already installed. I am surprised that previously clean
installation pulls in python310-jupyterlab through this ambiguity.
Suggestions to fix it without forcing python311 are welcome.
Good news! According to my tests, adding a simple `Recommends: python3-jupyterlab` is sufficient for zypper to consider the primary flavor first. https://build.opensuse.org/request/show/1104353 - Ben
On Thu, Aug 17, 2023 at 1:28 PM Ben Greiner <code@bnavigator.de> wrote:
The user has to do the selection by installing python3XX-jupyterlab. In
...
Good news! According to my tests, adding a simple `Recommends: python3-jupyterlab` is sufficient for zypper to consider the primary flavor first. https://build.opensuse.org/request/show/1104353
This means that if a user decided to not have the primary flavor at all for whatever reason and only has python310-jupiterlab, the python311-jupiterlab will still be pulled in. Whether it is of practical concern, I do not know. If you only want to influence selection when no jupiter package is present, it needs something like Recommends: (python3-jupyterlab unless python3dist(jupyterlab))
On Thu, Aug 17, 2023 at 12:54 PM Ben Greiner <code@bnavigator.de> wrote: ...
RPM boolean dependencies?
Requires: (python3.11dist(jupyterlab) if python3 == 3.11)
Requires: (python3.10dist(jupyterlab) if python3 == 3.10)
Requires: (python3.9dist(jupyterlab) if python3 == 3.9)
...
* python3 == 3.1X would only work for 3.1X.0 versions. python31X-base without any version would be the correct name
Well, I am not familiar with the details of python packaging. The idea is to require python3 - any version. I am sure you know much better than me how to do it.
* This installs jupyterlab and all of its dependencies for all installed python flavors, regardless whether the user wants it really for all flavors or whether the other flavors are installed for different reasons.
No, it /should/ install only the flavors for which python is already installed (or is being installed in the same transaction). If python3.9 is not present, python3.9-jupyterlab will not be required. OK, now when I spell it, "the same transaction" may not work with zypper which bypasses RPM transactions. Which is the same corner case "no python present".
* Every time the flavor build set changes, all the jupyter-* packages, which have the same python3dist idiom for the same purpose would need to be updated. (Or a macro automatically expanding it to the flavors needs to be introduced)
Of course if it is going to be implemented it must be a macro matching current %python_subpackages and automatically add dependencies for the same flavours.
Am 17.08.23 um 12:53 schrieb Andrei Borzenkov:
* python3 == 3.1X would only work for 3.1X.0 versions. python31X-base without any version would be the correct name Well, I am not familiar with the details of python packaging. The idea is to require python3 - any version. I am sure you know much better than me how to do it.
I think you lost the original issue out of sight. The existing `python3dist(jupyterlab)` is exactly for that: any flavor is okay. We were just looking for a way to nudge zypper into the right direction, when it has a choice to fulfill the "any". Seems that a simple `Recommends:`, or even a `Suggests:` as pointed out by Dimstar in https://build.opensuse.org/request/show/1104353, is enough. Much better than adding stuff to the already overcomplex singlespec macros. (Moreover, for a package which is not even considered for the singlespec rewriter)
* This installs jupyterlab and all of its dependencies for all installed python flavors, regardless whether the user wants it really for all flavors or whether the other flavors are installed for different reasons. No, it /should/ install only the flavors for which python is already installed (or is being installed in the same transaction). If python3.9 is not present, python3.9-jupyterlab will not be required.
Yes. If python3.9 is present that does not necessarily mean the full jupyterlab stack is desired on the machine as well. Python 3.9 could be present for another reason. - Ben
participants (13)
-
Andreas Schwab -
Andrei Borzenkov -
Axel Braun -
Axel Braun -
Ben Greiner -
Chuck Davis -
Fabian Vogt -
Felix Miata -
Jan Engelhardt -
Joe Salmeri -
Kilian Hanich -
Patrick Shanahan -
Robert Webb