[EPEL-devel] Re: EPEL7 python3/python36 standardization
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}- (python34-)
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
[EPEL-devel] Re: EPEL7 python3/python36 standardization
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}- (python34-)
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 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}- subpackage can simply rename it to
> > python3-. If the top level package is already python3-,
> > then the subpackage can be converted into the top level package. In
> > both cases, `%python_provide python3-` 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@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
--
Carl George
___
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
[EPEL-devel] Re: EPEL7 python3/python36 standardization
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}- subpackage can simply rename it to
> python3-. If the top level package is already python3-,
> then the subpackage can be converted into the top level package. In
> both cases, `%python_provide python3-` 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
signature.asc
Description: PGP signature
___
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
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
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 EPEL #topic Intros #topic Old Business #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9854/ ___ 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
[EPEL-devel] Re: EPEL7 python3/python36 standardization
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 purpose. On Thu, Jan 21, 2021 at 4:57 AM Andrew C Aitchison wrote: > > > 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 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. > > Do we need to be explicit about how we spell any value of these keys > - e.g. should it be >Requires: python >= 38 > or >Requires: python >= 3.8 > ? > > -- > Andrew C. Aitchison Kendal, UK > and...@aitchison.me.uk > ___ > 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 -- Carl George ___ 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
[EPEL-devel] Re: EPEL7 python3/python36 standardization
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 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 provide/obsolete python36-...). > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > -- Carl George ___ 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
[EPEL-devel] Re: EPEL7 python3/python36 standardization
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 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. Do we need to be explicit about how we spell any value of these keys - e.g. should it be Requires: python >= 38 or Requires: python >= 3.8 ? -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk ___ 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
[EPEL-devel] Re: EPEL7 python3/python36 standardization
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 provide/obsolete python36-...). -- 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
