On 28.2.2017 14:36, Thomas Bechtold wrote:
There is a product called SUSE OpenStack Cloud and that uses only python2 . And we don't want to add (and maintain) all the python3 versions for a huge dependency list just because some binaries need the py3 version.
(...)
The question is what we want to recommend. I stumbled over this while I started to create a py2pack spec template for the single spec approach.
well, the "recommended approach" so far has been to do alternatives for every throwaway executable the package would install, and that seems wrong to me. It's made worse by the fact that the vast majority of packages install the executable with an unversioned name, so it's additional work to either a) patch the setup.py file or b) catch the executable after installation and rename it --- made worse with singlespec by the fact that %python_install is now a single step. So let's look at the possible ways to resolve this. First, it is still perfectly possible to use alternatives, there's a couple of rather helpful macros for that too. So if the list of "some binaries" is small enough, we could keep what I recommended, and do alternatives only for the packages in the list. Then there's the fact that in a typical setuptools-based case, the "binary" is the exact same script with a different shebang. I could write a macro, i dunno, %python_clone_executable, that takes the named executable and creates "executable-%{python_version}" for every flavor. (I would still very much prefer the default, simplest case to be "only put executable in one package". Even if the other option is simplified to a macro and a couple of filelist entries.) Then it's a question of whether we need *alternatives* or whether shipping versioned binaries is good enough for your case? And if the latter, I'd stay off alternatives where not required, and keep with %python3_only %{_bindir}/unversioned-executable m.