[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse-packaging
Subject:    [opensuse-packaging] New thoughts on python singlespec macros
From:       Todd Rme <toddrme2178 () gmail ! com>
Date:       2017-11-14 18:29:05
Message-ID: CADb7s=u_2KoxaD6R-kpQkhaW9a_ejnzrqzsmme95M=hM1OrYZQ () mail ! gmail ! com
[Download RAW message or body]

Thinking about what we need for python3 conversion long-term, a few
issues have come to mind that currently aren't addressed well in the
macros or previous discussions:

1. We really need to get rid of using unversioned "python" in shebangs.
2. We need to switch everything over to use versioned rpm names
(particularly "python2-foo"), while still supporting older SLE/Leap
versions.
3. We need to be able to handle builds that don't include python2.
4. pytest often checks the directories being used, which breaks when
using "%python_expand"

Regarding 1, there are currently two pain points. First and most
obvious is the fact that the shebangs have to be edit manually.  The
second is that if we want versioned shebangs, we need to manually
recompile the files to avoid mtime issues.

Ideally changing the shebangs could be handled automatically during
%python_build, but there could still be a separate macro that could be
called in cases where manual changes are necessary.  Recompiling is
needed in other situations as well, so having a macro to handle that
would be useful in general.

Regarding 2, this is more of a policy issue. I think all packages,
even python2-only ones, should be switched over to using singlespec.
This makes sure that they have the correct name on all platforms.
Backports packages should have a conditional "skip_python3" that is
set to disable building for python versions equal to or greater than
the version they were backported from, even when those versions are no
longer shipped by openSUSE. There should also be a policy that, when
an upstream package drops python2 support, the last-supported python2
version should be made available in the "python2-foo" package.  Only
"python-foo-doc" and "python-foo-data" can have the unversioned
"python-" name, and that is only for version-independent documentation
and assets, respectively.

Regarding 3, there are again two main pain points. The first is that
there is no macro I am aware of to reliable determine if a given
python version is being built.  %have_python2 and %have_python3 no
longer work reliably AFAIK.

The second is that build dependencies for particular python versions
cannot be reliably disabled if that python version is not built.
Currently most packages that have a python2-only build dependency just
unconditionally require it, which means it will be pulled in even if
python2 builds are disabled.  Ideally I would like to see
"%{python2_module foo}" and "%{python3_module foo}" that will only
pull in that dependency if that version of python is being used.  This
also has the advantage of not needing to care about
backwards-compatibility issues of "python-foo" vs. "python2-foo"
names, which is handled inconsistently right now.  If that is not
feasible, just having a reliable check would be an improvement.

Regarding 4, I don't really understand what "%python_expand" is doing
behind the scenes, and whether there is a simple workaround or whether
the macro needs to do something different internally.
-- 
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

[prev in list] [next in list] [prev in thread] [next in thread]