On Tue, Apr 14, 2020 at 8:30 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 14. 04. 20 15:56, Troy Dawson wrote:
> Hi Miro,
> I've taken a look, but haven't done any testing.
Thanks.
> EPEL6 patch - no. Even if it works, I'd say no. We're at the last 7
> months before EOL and I don't want the EPEL6 stuff to have changes
> like this. I could be outvoted by this, but I believe most of the
> other EPEL packagers would feel this way.
Makes perfect sense.
> EPEL7 patch - This would require some testing. When we tried to turn
> on the python automatic-dependency checking, there were things that
> broke on EPEL7 so they never got implemented. What, or how they
> broke, I don't currently know. I just know that they did, and there
> wasn't a big enough demand to debug. As in zero demand. Nobody asked
> for it in EPEL7, only EPEL8. So I'm not even sure this would be worth
> the testing. Has anyone asked for this?
Not yet. But If we want packagers to start using %pycached, I know there are
some of them who would blindly merge their master branch to epel7 and they
expect it will work. I suggest that we backport %pycached only, the name is
unlikely to clash with anything. %python can be separated and not backported.
Sounds good?
Yep, sounds good to me.
> EPEL8 patch - We've had requests to have EPEL8 be as close
to Fedora,
> so I'm in favor of this.
> I'm pretty sure the %pycached shouldn't be a problem.
I agree.
> What is %python supposed to resolve to? To me it looks like
> /usr/bin/python ... which there isn't any in RHEL8. And, I thought
> Fedora got rid of it also, in favor of specifically doing python2 or
> python3. Or did that change?
So the main idea was that based on some FPC and RPMdevs discussions about
underscor-prefixed macros, packagers should not be using those directly, however
our guidelines were full of referecens to %{__python3}. We have come up with a
conclusion:
Macros with underscores, such as %__python3 are intended to be reset to change
bahvior of other macros (e.g. when you set %__python to /usr/bin/pythhon3.4 on
EPEL 7, %{python3_version{ will be 3.4), macros without underscores are to be
used in specs (e.g. you do `%{python3} -m pytest` rather than `%{__python3} -m
pytest`.
Details:
https://pagure.io/packaging-committee/issue/907
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/27#comm...
The only problem was the %{python} macro. When you redefine %__python to a sane
(explicit) value, you want %{python} to work, because e.g. %{python_version}
works. But we didn't want to encourage usage of "unversioned python" by
adding
%{python}.
So Fedora now has a %{python} macro: If %__python is /usr/bin/python (backwards
compatible default), %{python} gives you an error. If %__python is anything
else, %{python} gives that to you.
Fedora 32:
$ rpm --define '__python /usr/bin/python3.6' --eval '%python_version'
3.6
$ rpm --define '__python /usr/bin/python3.6' --eval '%python'
/usr/bin/python3.6
$ rpm --eval '%python_version'
3.8
$ rpm --eval '%python'
error: Cannot use %python if %__python wasn't redefined to something other than
/usr/bin/python.
EPEL 8:
$ rpm --define '__python /usr/bin/python3.6' --eval '%python_version'
3.6
$ rpm --define '__python /usr/bin/python3.6' --eval '%python'
%python
$ rpm --eval '%python_version'
error: attempt to use unversioned python, define %__python to /usr/bin/python2
or /usr/bin/python3 explicitly
$ rpm --eval '%python'
%python
Ahh ... now that you explain it, I was reading it totally backwards.
I'd still like to test it on a variety of packages, but unless others
have some type of objection, as long as it passes the tests, I'm good
with it.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok