Am 14.05.21 um 16:37 schrieb Ben Greiner:
To me, NanoVNA-Saver looks like an application rather than a library of modules to be imported by other modules/applications. Making it singlespec multi-python is probably not necessary or even desired. Better create a single nanovna-saver package without the %python_subpackages generator and use python3-foo dependencies. You can still leverage the python-rpm-macros. Even python_module, if you `%define pythons python3`.
Yes, NanoVNA-Saver is a application and is not thought as a library that can be used by other modules/applications. But from here: https://en.opensuse.org/openSUSE:Packaging_Python#Executables "For packages that carry executables you need to use %python_alternative to ensure easy switching between implementation for the binary for users." I read that as the singlespec multi-python using u_a for applications is a must and not an option. If that is optional, then it would be good when the wiki page could explain when singlespec multi-python + u_a should be used for an application.
If you really want to create packages for multiple python flavors, you can avoid file conflicts for the .desktop file and icon with at least two options:
1. Provide a desktop file and icon for every subpackage No need to make it u-a controlled. You will just have entries for every flavor in the application menu. sr#893151
2. Create a unflavored subpackage for the desktop file and icon. Only the u-a selected command will have a menu entry. sr#893153
Thanks a lot for those two examples. In the meantime I followed your first advice and removed the singlespec multi-python support from the package. Br, Frank