Bug 1216295 - /usr/bin/virt-manager breaks if i use update-alternatives to use a different Python
Summary: /usr/bin/virt-manager breaks if i use update-alternatives to use a different ...
Status: NEW
Alias: None
Product: openSUSE Distribution
Classification: openSUSE
Component: Virtualization:Tools (show other bugs)
Version: Leap 15.5
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Charles Arnold
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-10-17 06:08 UTC by ell1e
Modified: 2023-10-20 18:52 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description ell1e 2023-10-17 06:08:17 UTC 
virt-manager can't be easily launched anymore (most notably not through the GNOME shell launcher) if i use update-alternatives to use a different newer python, because then it won't find some packages it wants in the site packages when launched with a different one than what zypper intended for it to use.

This kind of renders the point of update-alternatives moot to me, I feel like I should be able to switch a different default Python for development without breaking basic graphical apps on the system. Therefore it seems to me like /usr/bin/virt-manager in particular should by default pick the correct version, the one it was installed for, when launched directly without specifying an interpreter (by which I mean running /usr/bin/virt-manager directly rather than doing "python /usr/bin/virt-manager" which I understand will always pick the update-alternatives changed version by principle).
Comment 1 ell1e 2023-10-19 16:56:05 UTC 
The cnf command seems to be broken by this as well:

$ cnf
Traceback (most recent call last):
  File "/usr/bin/cnf", line 8, in <module>
    import rpm
ModuleNotFoundError: No module named 'rpm'

If these programs all depend on a specific python version, I don't really get why the interpreter hashtag line in these /usr/bin scripts doesn't just specify that python interpreter version. (I assume that not being the case is the likely problem why they break now.)