Package: python3-pip
Version: 23.0.1+dfsg-1
Severity: normal
X-Debbugs-Cc: debbug.python3-...@sideload.33mail.com
In Bullseye, an app was installed as follows:
===8<----------------------------------------
$ torsocks pip3 install argostranslate
$ torsocks pip3 install --log-file $logs_dir/pip3-argostranslategui.err --log
$logs_dir/pip3-argostranslategui.log --cache-dir /usr/local/tarballs
argostranslategui
$ torsocks argospm install translate-${lang1}_$lang2
===8<----------------------------------------
It ran fine. Then an update to the latest Bullseye point release was
performed, followed immediately with an “aptitude full-upgrade”. A
full log of the upgrade was not kept, but I did note this conflict:
===8<----------------------------------------
python3-virtualenv : Depends: python3-pip-whl but it is not going to be
installed
Depends: python3-setuptools-whl but it is not going to be
installed
===8<----------------------------------------
It’s probably irrelevant because aptitude’s resolution resulted in a
functioning python/pip - but worth mentioning in case it matters. An
attempt to execute the app after the upgrade to Bookworm went like
this:
===8<----------------------------------------
$ /usr/local/bin/argos-translate -v
Traceback (most recent call last):
File "/usr/local/bin/argos-translate", line 3, in <module>
from argostranslate import cli
ModuleNotFoundError: No module named 'argostranslate'
$ pip3 list | grep -i argo
(no output)
$ pip list | grep -i argo
(no output)
===8<----------------------------------------
It’s also a bug for pip3 to have lost track of the fact that it
managed the app. Running “pip3 list” should reveal the existence of
the app.
I’m told it would have been wise to have installed the app in a
virtual environment not in the system (likely accurate). But
nonetheless a needed app module should never be silently dropped
without informing the user in the very least. If a needed module
needed to be scrapped for some reason, ideally a signal would be sent
to the apt procedure to block the upgrade and inform the user of steps
needed.
Recapping, I see four bugs:
① (upstream) an app module was dropped/lost
② (upstream) the user was not informed about the loss
③ (debian) the anomaly failed to block aptitude from moving forward
④ (upstream) pip3 lost track of the fact it was managing the app
I did not apply the upstream tag because bug 3 above is debian
related. But this report should probably be seen by upstream devs as
well.
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990,
'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-pip depends on:
ii ca-certificates 20230311
ii python3 3.11.2-1+b1
ii python3-distutils 3.11.2-3
ii python3-setuptools 66.1.1-1
ii python3-wheel 0.38.4-2
Versions of packages python3-pip recommends:
ii build-essential 12.9
ii python3-dev 3.11.2-1+b1
python3-pip suggests no packages.
-- no debconf information
