Package: gstreamer1.0-python3-plugin-loader Version: 1.18.3-1 When building gst-python1.0, it creates a dependency on libpython3.x for the binary package gstreamer1.0-python3-plugin-loader. However, that binary also depends on python3-gi. We are rebuilding all packages we ingest from Debian. It so happens that we rebuilt python3-gi after an upgrade of python3-defaults (the upgrade that removed building against python 3.8). However, dependency tracking did not rebuild gst-python1.0 because the library the resulting binary depends on (libpython3.8 in this case) was still available.
This resulted in gstreamer1.0-python3-plugin-loader with Depends: libpython3.8 python3-gi with Depends: python3 (>3.9~), python3 (<3.10) To be fair, I have no good idea how to handle this in a better way and make the situation clearer. So if you don't think there is a better way to express the dependencies, feel free to close this bug. Before doing that, please read on though: I thought of: - Let python3-gi conflict with libpython3.8 if it only has libpython3.9 support Disadvantage: Prevents any package depending on libpython3.8 from being co-installed, even if that isn't using python3-gi - Let gstreamer1.0-python3-plugin-loader depend on libpython3 (>= 3.8~), libpython3 (<3.10) Disadvantage: Doesn't allow python3-gi (and other packages) get upgraded, even if they still support libpython3.8 (but the default is at 3.9) The second _seems_ like the best option to me, as I think python3-defaults typically adds the new version first, then switches the default and finally removes the old version. I also realize this doesn't directly affect Debian itself, as Debian tooling does make sure the packages are installable at the time of migration to Testing and you ensure to rebuild when needed. The above would just make it easier for tooling to track when the package needs to get rebuilt (though typically, there are enough upstream updates to make sure of that). Kind regards, Sven
