I think it's a fine idea, but I don't personally need it and don't
have time to help.
I think redefining %__python3 to /usr/bin/python3.9 on a per-specfile
basis is fine, as long as we leave the default value
(/usr/bin/python3.6) from RHEL alone. I'm not a fan of the
%__python3_other macros, and would be happy to see them go away when
python34 is retired (which can happen independently of python3.9).
On Wed, Apr 7, 2021 at 2:36 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 07. 04. 21 4:50, Carl George wrote:
> What do you mean by support? The only thing EPEL supports (using the
> term loosely) is enabling Fedora packagers to branch and build their
> packages for EPEL. Any maintainer of the Fedora python3.9 package (or
> any related package necessary for bootstrapping) can request an epel7
> branch and start building. The main thing to be aware of is to comply
> with EPEL policy [0], especially the part about not
> replacing/disturbing the base distribution. RHEL7 includes python3,
> so an epel7 python3.9 build would need to ensure it doesn't conflict
> with any filesystem paths from that package.
I believe the confusion is my fault.
By "support" I've meant: Does EPEL-devel generally agree that adding Python
3.9
to EPEL 7 is a good idea, even if we don't phase out Python 3.4 at the same time?
E.g. building RPMs for Python 3.9 in EPEL would require redefining %__python3
(or %__python3_other).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Carl George