On 2.3.2018 11:50, Pavel Raiskup wrote:
On Friday, March 2, 2018 11:32:40 AM CET Miro Hrončok wrote:
On 2.3.2018 11:25, Pavel Raiskup wrote:
On Friday, March 2, 2018 10:36:36 AM CET Miro Hrončok wrote:
I've prepared a draft for Python packaging that introduces some new macros that should ease packaging for Fedoras, EPELs and even potential new RHELs, when it comes to python stacks.
I don't do much ifs in specfiles and prefer to leverage git branches for this, so I don't know what bothers you most. The proposal with example spec file is at:
https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros [..snip..] Could you please provide feedback? Ask questions?
What's the real usecase for *_must?
This tells you that according to the guidelines for given distro, if upstream supports this python version, you MUST package for it. Some packages might want to only package their Python library for the stacks where it's required.
FWIW, I don't think macros should be used to _enforce_ guidelines (should be rather convenient things which everyone loves to use). But no problem, as long as I don't have to use that. Just saying that it might be a bit confusing when reading the (draft) wiki...
They don't enforce anything. They just make it possible to get the value defined by the guideline in a technical manner and do with the value whatever you please. It's still up to the packager to decide what to do when py3_must is 1 or when it's not.
If the wiki is confusing, I can try to reword the description. However I'm afraid everybody will just jump to the table anyway.
Why the py2_must is not defined for epel7 and epel6?
Because there is no such guideline. It is completely OK to package for python3 only on EPELs.
I always only needed to see whether (a) python2 runtime is available, (b) python3 is available. So more readable and understandable approach (to me) would be to have only the %pyX_may (or %py3_available). But I'm probably not experienced enough, so I'm only curious :-).
For that, yes. here may == available. We can discuss the naming if it sounds weird.
E.g. last time (argparse-manpage) I went with:
%if 0%{?fedora} %bcond_without python2 %bcond_without python3 %else %if 0%{?rhel} > 7 %bcond_with python2 %bcond_without python3 %else %bcond_without python2 %bcond_with python3 %endif %endifWhich allows me to do things like:
%if %{with python2} .... %endifOr:
BuildRequires: %{?with_python3:foo} %{?with_python2:bar}.. and which brings the convenient --with{,out}-python{2,3} options for custom re-builds. Could we have something similar in the draft, too?
We can definitively make those with statemetns, however we cannot make it with_python2 and with_python3, because we might destroy current specfiles with that. So we would need to have:
%if %{with python2_must} .... %endifOr:
BuildRequires: %{?with_python3_may:foo} %{?with_python2_must:bar}And specifying those on the command line would be rather unreadable. What does --with-python2-may even mean?
--with-py3 or --with-py3-available doesn't soudd that bad, but ..
I wouldn't worry about existing spec files.. and I would stick with --with-python2 (and friends). Existing spec files should not depend on the distro-default value, since no distro so far defined that; which means that whatever value is defined in spec file will _just_ override the new system default. For the few remaining packages (are there any?), well, there go proven packagers...?
I hear you. I like the idea Petr just sent to python-devel, so lets continue from there.