----- Original Message -----
On Tue, Jan 27, 2015 at 06:26:26AM -0500, Bohuslav Kabrda wrote:
>
> Current state:
> - Up until F21, maintainers were encouraged to build applications with
> Python 2, but weren't discouraged from building with Python 3.
Note -- this isn't quite right. If an application could run with either
python2 or python3 maintainers in F21 and below were supposed to have the
app run with python2. F22 is supposed to flip this so that maintainers are
supposed make these packages run with python3 instead of python2.
I guess that I interpreted it my way since I didn't see any "must" in
there... But ok, thanks for the clarification :)
> - From F22 on, packagers will be encouraged to build with Python
3 rather
> than Python 2.
> - Lots of packagers want to keep the same specfile for EPEL and Fedora.
> - Fedora guidelines mandate explicit usage of %__python2 and %__python3
> (and all the sitelib/sitearch macros).
>
> The Problem:
> If packagers want to build against Python 3 in Fedora and Python in EPEL
> *and* keep the same specfile, they have to invent some ugly hacks, since
> Fedora's guidelines require explicit usage of versioned Python macros.
> This affects Requires and BuildRequires and %prep, %build, %install,
> %check sections. People who want to do this either redefine %__python in
> Fedora to point to Python 3 or something like that - I'm afraid that we
> could end up with a huge pile of crazy macro redefinitions in tons of
> packages and I want to avoid that.
>
> Proposed Solution:
> After thinking a few days about this, here's what I propose:
> - Every specfile will have a minimal header with macro definitions that
> will look like this:
>
> %if 0%{?fedora}
> %global default_python python3
> %else
> %global default_python python
> %endif
>
> %make_default_python %default_python
>
> - The %make_default_python macro function will point all the unversioned
> macros to proper values for given %default_python:
>
> ### In Fedora
> %{__python} -> /usr/bin/python3
> %{python_sitelib} -> /usr/lib/python3.X/site-packages
> # and other macros...
>
> ### In EPEL
> %{__python} -> /usr/bin/python2
> %{python_sitelib} -> /usr/lib/python2.X/site-packages
> # and other macros...
>
I'm not really a fan of redefining existing macros like this. The problem
is the same as the python2 "from __future__ import unicode_literals"
statement. It causes your existing knowledge of how things work to betray
you. And recognizing that the change is present requires you to look
somewhere far away from the code that you are actually interested in.
Right, I guess I'll just agree on disagreeing with you on this :) I don't think
it's a problem the same way I don't think "from __future__ import
unicode_literals" is a problem.
> - This means that packagers will be able to use the unversioned
macros
> throughout their specfile. Requires and BuildRequires will look like this:
>
> Requires: %{default_python}-flask
> BuildRequires %{default_python}-setuptools
>
> Note: since BuildRequires need to be expanded in the minimal buildroot,
> it's necessary to define the %default_python macro in the specfile. Other
> way would be to define it in a macro file that would be added to the
> minimal buildroot, but that's neither very likely nor very nice :)
>
Have you talked to dennis? We've added packages to the minimal BuildRoot
many times before in order to enable macro files. Not so problematic if
it's only one macro, though.
I will. Do you have any idea who I should talk to regarding EPEL? Is it also Dennis?
>
> I think this solution makes sense for *applications* that need to be built
> both in Fedora and in EPEL. Note that it'd also align with my EPEL-python3
> proposal [1], in case such an app was to be moved to python3X in EPEL
> (%default_python would just be redefined to "python3X"). I also think
that
> this approach should never be allowed for packaging "libraries", e.g.
> packages that have python-foo and python3-foo subpackages.
>
> Thoughts?
If we were to use different macro names instead of overwriting currently
well known ones I think this has merit.
For me, introducing yet another set of macros is unnecessary. I think that it'd
introduce a long(-ish) new part of guidelines that'll make them even more complicated
than they are right now (compared to one new macro function and rules on how/when to use
it).
-Toshio
Slavek