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 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.
Well, technically, to match RHEL7's prefixes, python- is Python 2. But I'd
rather keep it explicitly python2-, as Carl suggests.
EPEL7: python2-, python3-, python34- (but recommend not building for 3.4)
EPEL8: python2-, python3-, python38- (but recommend not building for 2.7)
EPEL 8 note: We could possibly override %python_provide/%py_provides to provide
python36- for pytohn3- and vice versa. In RHEL proper, this does AFAIK not
happen, but it might, if EPEL representatives speak up in this bugzilla about
macro backports (really quickly, pull request is on review):
https://bugzilla.redhat.com/show_bug.cgi?id=1892797
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.
We still have a couple years with EPEL 7, it is most likely worth the effort.
Any security fix now has to be backported from 3.6 as 3.5 is also EOL, and with
time, this will only get worse.
As always, if we keep Python 3.4 in EPEL7, work is needed. See e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=1918176 (high severity CVE)
https://bugzilla.redhat.com/show_bug.cgi?id=1765139 (medium severity CVE)
https://bugzilla.redhat.com/show_bug.cgi?id=1763231 (medium severity CVE)
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.
I agree. Not worth mass changing the packages for the prefix. Possibly together
with python34- package removal.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
