On Thu, 21 Jan 2021, Carl George wrote:
RHEL7 ships Python 3.6 packages using the python3 prefix. Currently
EPEL7 contains Python 3.6 packages using both the python3 and python36
prefixes. Thanks to the foresight and preparation work of the Red Hat
Python Maintenance team, these work
On 21. 01. 21 7:19, Carl George wrote:
I propose that we standardize
on the python3 prefix to match RHEL7 packages and document in EPEL
guidelines that maintainers SHOULD use the python3 prefix.
I'm fine with that, is we also say they MUST use %python_provide (or that the
packages MUST
On Thu, Jan 21, 2021 at 12:19:39AM -0600, Carl George wrote:
> Howdy folks,
>
> RHEL7 ships Python 3.6 packages using the python3 prefix. Currently
> EPEL7 contains Python 3.6 packages using both the python3 and python36
> prefixes. Thanks to the foresight and preparation work of the Red Hat
>
Agreed. And if a maintainer decides to stick with the python36 name,
they MUST provide the equivalent python3 name. I've captured those
for what I'll add to the guidelines.
On Thu, Jan 21, 2021 at 4:30 AM Miro Hrončok wrote:
>
> On 21. 01. 21 7:19, Carl George wrote:
> > I propose that we
I'm not sure I understand your question. This proposal is about
python36 packages, not the existing python34 packages or hypothetical
python38 packages. In any case, packages shouldn't be requiring
python* directly. They automatically get a requirement on
`python(abi) = X.Y` that serves this
Dear all,
You are kindly invited to the meeting:
EPEL Steering Committee on 2021-01-22 from 17:00:00 to 18:00:00 US/Eastern
At fedora-meet...@irc.freenode.net
The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.
A general agenda is the following:
#meetingname
On 21. 01. 21 21:38, Carl George wrote:
I had originally hoped to limit this guideline change to EPEL7's
python36 packages, not EPEL7's python34 packages or anything about
EPEL8. But I do see the appeal of taking it a step further to lay out
the guidelines for all EPEL python packages. The
I had originally hoped to limit this guideline change to EPEL7's
python36 packages, not EPEL7's python34 packages or anything about
EPEL8. But I do see the appeal of taking it a step further to lay out
the guidelines for all EPEL python packages. The overall intent is to
have EPEL python package
