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 prefixes match the RHEL python stack they are
intended to work with. That means the recommended prefixes for EPEL7
would be python and python3. The recommended prefixes for EPEL8 would
be python2, python3, and python38.
Regarding EPEL7's python34 packages, all the changes discussed here
can take place without modifying the
python%{python3_other_pkgversion}-<name> (python34-<name>)
subpackages. EPEL7's python34 packages should just be retired as that
Python version is EOL upstream, but so far no one (myself included)
has stepped up to drive that effort. I don't know if it's worth the
effort, as surely some will complain about it being removed,
regardless of the upstream status.
I think a tracker bug would only be necessary if we made the prefix
recommendations a MUST. As a SHOULD, it would be fine to let packages
get corrected naturally over time. The important piece would be to
have the guideline in place for package reviews to reference, to
prevent any further packages using non-standard prefixes from being
added.
On Thu, Jan 21, 2021 at 11:28 AM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
>
> 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
> _______________________________________________
> epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
--
Carl George
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
