On 10/31/2016 11:51 AM, jan matejek wrote:
On 29.10.2016 11:57, Robert Schweikert wrote:
Making the package names explicit with respect to the version would get people used to a disassociation of the command line name and the associated packages. Today, with the Python-2 interpreter being the default one uses "python" on the command line and installs modules with binary packages called "python-foo". Thus there is a nice match in names. However, at some point in the future the "python" command will start the Python-3 interpreter and then all of a sudden one has to install "python3-foo" to use the module. So my thought is, if we break this association now, while Python-2 is still the default, then the change when Python-3 becomes the default is not going to be as traumatic as people will already be used to not having the "python" command and the binary package names be associated by name.
At this point it seems realistic to aim to switch the default python to Python 3 in SLE 13.
Well I am not necessarily certain that SLE should be a determining factor here. We should consider when there is a realistic expectation to switch :Factory to Python 3 as the default. We are talking about a development project for openSUSE after all and SLE branches from Tumbleweed.
For that, we would need to rename "python" to "python2", and keep "python" just as a provided symbol. This might also be an opportunity to move to "python2-foo" + "python3-foo" and make "python-foo" just a provided symbol too.
This way the association is never broken.
So we agree :) , but for me this implies that our binary packages should start being named as python2-foo and python3-foo rather sooner than later. If that cannot be handled via macro magic, although I am not certain why it couldn't, then yes we'd end up having to do a renaming exercise, so be it. But I could imagine that we can come up with something like: Name: %{python_version_name}-foo and %ifdef %{is_python_default_version} Provides: python-foo %endif Then python_version_name expands to python2 and python3 respectively on two consecutive builds, thus creating binary packages of python2-foo and python3-foo. As long a Python-2 is the default the python2-foo build creates the Provides: entry in the package and when we switch to Python-3 then the python3 package build will get the provides. So this means we still have to touch every spec file in d:l:p but we do not have to rename the packages per-se. And we will end up having to touch all the .spec files in d:l:p anyway when we move to a new macro set. For packages that are only Python-2 they'd get Name: python2-bar and %ifdef %{is_python_default_version} Provides: python-foo %endif Packages that are only Python-3 get Name: python3-bar and %ifdef %{is_python_default_version} Provides: python-foo %endif If we do want to think about Python-4 then those should also be macros but I am not certain we need to go there.
(Please note that at this point there is no concrete plan for the switch. It's just what seems realistic to me personally.)
I agree I don't think we should start to evict packages from d:l:p based on some nebulous arbitrary policy decision. If an application is written in Python it should be able to live in d:l:p. Chances are the application provides some modules that are useful for other purposes and the maintenance burden is reduced on the maintainer.
OTOH, if you want to add a repository for, say, all geodesics packages, you shouldn't need to add Application:Geo ... AND d:l:py and d:l:ruby and d:l:haskell and d:l:javascript and d:l:intercal, just because some of your geodesics apps happen to be written in a particular language.
I don't think this is what anyone is saying. If there is Application:Geo and people want to stick their Python based app there that is great. However they still end up having to link some of d:l:p as it is unlikely that myGeoApp only depends on stuff that is part of Python. Alternately the packager may decide that myGeoApp could/should live in d:l:p to avoid the linking stuff all together. In any event I think this is a topic that is only tangentially related to how we handle integrated builds for python2 and python3 from a single spec file. As we go and touch all the spec files we might run into cases where we might decide that something may be better off having a new home and we can then engage that maintainer, but I am very hesitant to a.) intermingle the two topics (integrated python build and "what should live in d:l:p") and b.) continue to speak in the abstract without having concrete examples where and how these new proposed rules would/could apply. From my perspective we should focus on the prize, which is an integrated build. Everything else is a distraction and we cannot boil the ocean. Co-mingling of topics makes things bigger and may bring us to the point where once again nothing gets done. Thus rather than going down a rat hole I'd rather find consensus on the key topics, which appears to me that we are not really all that far away, and then actually get something done, rather then discuss tangentially related items. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo