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
Python Maintenance team, these work interchangeably when using the
%python_provide macro. However the situation is still confusing for
packagers and users. We never formalized guidelines on which prefix
to use. I would like to change that. 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.
Transitioning packages is straightforward. Packages using a
python%{python3_pkgversion}-<name> subpackage can simply rename it to
python3-<name>. If the top level package is already python3-<name>,
then the subpackage can be converted into the top level package. In
both cases, `%python_provide python3-<name>` handles the necessary
provides and obsoletes. This work doesn't need to happen all at once,
and maintainers can opt in as they have time. We already have a mix
of prefixes, this is just about nudging towards python3 as the correct
prefix.
Please share your feedback, and I'll present this proposal and the
feedback to the EPEL Steering Committee.
Seems like anoying churn to change them, but I guess standardizing is
good. Perhaps we could generate a list of python36 and python34
subpackages that need changing and make a tracker bug and the
epel-packagers sig could drive forward filing bugs/pr's/just fixing
these?
For epel8: I see there's one python38 package in epel8 ( python38-radicale3 )
do we want to also standardize there also to python3-name? Since there's
multiple python stacks there we really might have need for being more
specific there, so that might be fine, but we should probibly note it.
kevin