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