On Tue, Nov 04, 2025 at 01:22:48AM +0100, Marek Marczykowski-Górecki wrote: > On Mon, Nov 03, 2025 at 03:26:01PM -0800, Elliott Mitchell wrote: > > Are Python 3 scripts. > > If it would be just about scripts, it should be possible to make it > depends on any python3 version, but there are also a bunch of python > libs: > /usr/lib/xen-4.20/lib/python/grub/ExtLinuxConf.py > /usr/lib/xen-4.20/lib/python/grub/GrubConf.py > /usr/lib/xen-4.20/lib/python/grub/LiloConf.py > /usr/lib/xen-4.20/lib/python/grub/__init__.py > /usr/lib/xen-4.20/lib/python/pygrub-0.7.egg-info/PKG-INFO > /usr/lib/xen-4.20/lib/python/pygrub-0.7.egg-info/dependency_links.txt > /usr/lib/xen-4.20/lib/python/pygrub-0.7.egg-info/top_level.txt > /usr/lib/xen-4.20/lib/python/xen-3.0.egg-info/PKG-INFO > /usr/lib/xen-4.20/lib/python/xen-3.0.egg-info/dependency_links.txt > /usr/lib/xen-4.20/lib/python/xen-3.0.egg-info/top_level.txt > /usr/lib/xen-4.20/lib/python/xen/__init__.py > /usr/lib/xen-4.20/lib/python/xen/lowlevel/__init__.py > /usr/lib/xen-4.20/lib/python/xen/lowlevel/xc.cpython-313-x86_64-linux-gnu.so > /usr/lib/xen-4.20/lib/python/xen/lowlevel/xs.cpython-313-x86_64-linux-gnu.so > /usr/lib/xen-4.20/lib/python/xen/migration/__init__.py > /usr/lib/xen-4.20/lib/python/xen/migration/legacy.py > /usr/lib/xen-4.20/lib/python/xen/migration/libxc.py > /usr/lib/xen-4.20/lib/python/xen/migration/libxl.py > /usr/lib/xen-4.20/lib/python/xen/migration/public.py > /usr/lib/xen-4.20/lib/python/xen/migration/tests.py > /usr/lib/xen-4.20/lib/python/xen/migration/verify.py > /usr/lib/xen-4.20/lib/python/xen/migration/xl.py > /usr/lib/xen-4.20/lib/python/xen/util.py > /usr/lib/xen-4.20/lib/python/xenfsimage.cpython-313-x86_64-linux-gnu.so
Guess I missed explicitly stating it, but I expected these to travel with the scripts. Actually I wonder whether the Python version dependency is *strictly* the libraries while the scripts might work with a much wider range of Python versions. > Some of those might be used by other software. Not visible in Debian. Nothing outside of src:xen depends on xen-utils-X.YY, so if this is so then something has a packaging error. > > I would suggest creating xen-utils-X.YY-python to split the Python > > scripts out of the main xen-utils-X.YY package. > > That might help, if such xen-utils-X.YY-python would not be installed > (or at least would not be needed during upgrade). But is it the case? The *stream* scripts are likely for loading/transfering in VM images. I certainly hope no one plans to transfer live VMs in *during* an update. The bigger issue is when installing Xen 4.20 on a system currently running Xen 4.17, you *urgently* want to have most 4.17 and 4.20 utilities installed simultaneously. Only once 4.20 is confirmed operational should one remove the 4.17 utilities. In particular due to them conflicting you must follow a series of steps. First, install hypervisor 4.20. Second, stop/migrate all currently operational VMs. Third, reboot. Fourth, install xen-utils-4.20. You cannot install the 4.20 utilities before reboot since you lose the ability to stop currently running VMs. This is particularly troublesome if your bastion host happens to be a VM. > > Other trick is grub-xen-host sort of makes PyGRUB deprecated. > > TBH, it's a good idea to get rid of PyGRUB anyway, for so many > reasons... Indeed. For x86 I think it would be a Fine Idea to remove PyGRUB from future xen-utils-X.YY packages. For ARM, until PyGRUB gets ported to ARM it needs to remain. The other bootloader which I've gotten good results with is Tianocore/EDK2. That though has an outstanding crucial bugfix, but also needs to be ported to x86. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | [email protected] PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
