Overview
Request 856028 accepted
- Move the alternative binary to the flavored python package
- Created by bnavigator
- In state accepted
-
Package maintainer:
bnavigator
Loading...
Request History
bnavigator created request
- Move the alternative binary to the flavored python package
mcalabkova accepted request
ok
why? I see it is some staging (could you please tell me which one?), but I still can't see the logic behind this. Why to move something which clearly belongs only to subpackage to the main package?
No it is the entrypoint, which calls the module from the correct python3 flavor. Hence the alternative logic, which is not changed here.
the jupyter- package is actually only the icon and the desktop file pointing to the alternative.
I still don't like it. Why does it have the same name, in such a case? And how is it broken? Maybe I should leave this request to Matěj... :)
because %python_alternative does not work for the unflavored "-n jupyter-" package. This does not produce any alternatives to choose from.
ok, thanks, now I understand :)
if you didn't know already: this is all related to gh#openSUSE/python-rpm-macros#66
most jupyter packages are not in Ring1, so they are not directly relevant to Staging:N, but Factory will have a lot of failures or unresolvables related to jupyter if :N goes through.