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"
"python2", and keep "python" just as a provided symbol. This might
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:
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
Packages that are only Python-3 get
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
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
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.
Robert Schweikert MAY THE SOURCE BE WITH YOU
Public Cloud Architect LINUX