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
%endif
Which allows me to do things like:
%if %{with python2}
....
%endif
Or:
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}
....
%endif
Or:
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
