Hey,
when RHEL 7.7 will be released, the following new components/packages will be provided (assuming from 7.7 beta):
python3 - the Python 3.6 package ================================
This new RHEL7 component builds several subpackages, all obsoleting the subpackages of epel7 python36 package. We will simply retire python36 from epel7.
python-rpm-macros =================
This new RHEL7 component is a drop-in replacement of python-rpm-macros from epel7, we will simply retire the package. python-epel-rpm-macros already provide the necessary macros for python34 in epel7.
python3-setuptools ==================
This new RHEL7 component produces the python3-setuptools package that obsoletes the python36-setuptools package (built from the python3-setuptools epel7 component).
We cannot simply retire python3-setuptools from epel7, as it also builds python34-setuptools in epel7 and there is no replacement for that in RHEL7.
Easiest thing would be to stop building python36-setuptools and only keep python34-setuptools in epel7, however IIRC we cannot have the same component name as in RHEL. If that is indeed the case, python3-setuptools needs to be retired and a new python34-setuptools component needs to be created in epel7. Is my assumption correct?
python-pip ==========
This new RHEL7 component produces the python3-pip package that obsoletes the python36-pip package (built from the python-pip epel7 component).
The python-pip epel7 component also produces python34-pip and python2-pip (neither available in RHEL 7.7).
If my previous assumption about components with RHEL names is correct, we need 1 or 2 new components for python34-pip and python2-pip - either we have each in a separate component or we create a new component that builds both (called python-pip-epel maybe?).
python-wheel ============
This new RHEL7 component produces the python3-wheel package.
The python-wheel epel7 component produced python-wheel package (Python 2).
The epel7 package was adapted to produce python2-wheel and python36-wheel, however there was no successful build of this in epel7.
If my previous assumption about components with RHEL names is correct, we need to add a new python2-wheel component to epel7.
------------
Are my assumptions correct?
If we indeed need new packages/components, I can help to create them, but I do not intent to maintain them. Any takers?
"MH" == Miro Hrončok mhroncok@redhat.com writes:
MH> Are my assumptions correct?
Yes, unless some major changes happened of which I was not aware, you cannot have any package name in EPEL7 (including a source package) which duplicates a package name in RHEL7 _on a particular architecture_. (There are limited-arch packages as described at https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages).
In the cases you mention, I do believe you would need new source package repositories to avoid the conflict. Note that creating these does not require a package review as long as they are named properly.
- J<
On 17. 07. 19 0:00, Miro Hrončok wrote:
...we need 1 or 2 new components for python34-pip and python2-pip - either we have each in a separate component or we create a new component that builds both (called python-pip-epel maybe?).
What is the advice here? If I want it to be just one package, what shall be its name?
On Thu, 25 Jul 2019 at 08:21, Miro Hrončok mhroncok@redhat.com wrote:
On 17. 07. 19 0:00, Miro Hrončok wrote:
...we need 1 or 2 new components for python34-pip and python2-pip -
either
we have each in a separate component or we create a new component that builds both (called python-pip-epel maybe?).
What is the advice here? If I want it to be just one package, what shall be its name?
Sorry, I completely missed that there were points you needed answers on. Are there any others in the proposal we need to focus on?
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@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...
On Thu, 25 Jul 2019 at 08:46, Stephen John Smoogen smooge@gmail.com wrote:
On Thu, 25 Jul 2019 at 08:21, Miro Hrončok mhroncok@redhat.com wrote:
On 17. 07. 19 0:00, Miro Hrončok wrote:
...we need 1 or 2 new components for python34-pip and python2-pip -
either
we have each in a separate component or we create a new component that builds both (called python-pip-epel maybe?).
What is the advice here? If I want it to be just one package, what shall be its name?
Sorry, I completely missed that there were points you needed answers on. Are there any others in the proposal we need to focus on?
And there are clearly multiple based around this one: however IIRC we cannot have the same component name as in RHEL. If that is indeed the case, python3-setuptools needs to be retired and a new python34-setuptools component needs to be created in epel7. Is my assumption correct?
Yes your assumption is correct. Koji uses src.rpm names to determine what it pulls into a buildroot. That means that the python34 items need to have non-conflicting names with the python3 ones shipped by upstream.. or we will just start building with python34 or worse.
Would it make sense to just retire python34 completely from EPEL at the 7.7 release date?
-- Stephen J Smoogen.
On 25. 07. 19 14:51, Stephen John Smoogen wrote:
Yes your assumption is correct. Koji uses src.rpm names to determine what it pulls into a buildroot. That means that the python34 items need to have non-conflicting names with the python3 ones shipped by upstream.. or we will just start building with python34 or worse.
I've already prepared python34-setuptools:
https://src.fedoraproject.org/rpms/python3-setuptools/pull-request/4 https://bugzilla.redhat.com/show_bug.cgi?id=1733190
And python2-wheel:
https://src.fedoraproject.org/rpms/python-wheel/pull-request/10 https://bugzilla.redhat.com/show_bug.cgi?id=1733193
I'm waiting for the name suggestion for python{2,34}-pip.
Would it make sense to just retire python34 completely from EPEL at the 7.7 release date?
Python 3.4 is upstream unsupported, so getting rid of it sooner than later is probably a good idea. However, I suggest to keep it around until EL6 is EOL.
On 25. 07. 19 15:30, Miro Hrončok wrote:
I'm waiting for the name suggestion for python{2,34}-pip.
Is python-pip-epel fine? Or should it be 2 source RPMs?
On 29. 07. 19 13:17, Miro Hrončok wrote:
On 25. 07. 19 15:30, Miro Hrončok wrote:
I'm waiting for the name suggestion for python{2,34}-pip.
Is python-pip-epel fine? Or should it be 2 source RPMs?
I went with python-pip-epel, since nobody seems to mind that one:
https://bugzilla.redhat.com/show_bug.cgi?id=1737028 https://src.fedoraproject.org/rpms/python-pip/pull-request/39
On Tue, Jul 16, 2019, 3:48 PM Miro Hrončok mhroncok@redhat.com wrote:
Hey,
when RHEL 7.7 will be released, the following new components/packages will be provided (assuming from 7.7 beta):
python3 - the Python 3.6 package
This new RHEL7 component builds several subpackages, all obsoleting the subpackages of epel7 python36 package. We will simply retire python36 from epel7.
python-rpm-macros
This new RHEL7 component is a drop-in replacement of python-rpm-macros from epel7, we will simply retire the package. python-epel-rpm-macros already provide the necessary macros for python34 in epel7.
python3-setuptools
This new RHEL7 component produces the python3-setuptools package that obsoletes the python36-setuptools package (built from the python3-setuptools epel7 component).
We cannot simply retire python3-setuptools from epel7, as it also builds python34-setuptools in epel7 and there is no replacement for that in RHEL7.
Easiest thing would be to stop building python36-setuptools and only keep python34-setuptools in epel7, however IIRC we cannot have the same component name as in RHEL. If that is indeed the case, python3-setuptools needs to be retired and a new python34-setuptools component needs to be created in epel7. Is my assumption correct?
python-pip
This new RHEL7 component produces the python3-pip package that obsoletes the python36-pip package (built from the python-pip epel7 component).
The python-pip epel7 component also produces python34-pip and python2-pip (neither available in RHEL 7.7).
If my previous assumption about components with RHEL names is correct, we need 1 or 2 new components for python34-pip and python2-pip - either we have each in a separate component or we create a new component that builds both (called python-pip-epel maybe?).
python-wheel
This new RHEL7 component produces the python3-wheel package.
The python-wheel epel7 component produced python-wheel package (Python 2).
The epel7 package was adapted to produce python2-wheel and python36-wheel, however there was no successful build of this in epel7.
If my previous assumption about components with RHEL names is correct, we need to add a new python2-wheel component to epel7.
Are my assumptions correct?
If we indeed need new packages/components, I can help to create them, but I do not intent to maintain them. Any takers?
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@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...
On 17. 07. 19 0:00, Miro Hrončok wrote:
Hey,
when RHEL 7.7 will be released, the following new components/packages will be provided (assuming from 7.7 beta):
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-31bd12e515
Please somebody do a sanity check, so I can retire python-pip, python3-setuptools and python-wheel.
I have tested python2-wheel and it worked. Looking to see what needs to be done for th eohters.
On Fri, 9 Aug 2019 at 10:27, Miro Hrončok mhroncok@redhat.com wrote:
On 17. 07. 19 0:00, Miro Hrončok wrote:
Hey,
when RHEL 7.7 will be released, the following new components/packages
will be
provided (assuming from 7.7 beta):
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-31bd12e515
Please somebody do a sanity check, so I can retire python-pip, python3-setuptools and python-wheel.
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@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...
On 09. 08. 19 16:49, Stephen John Smoogen wrote:
I have tested python2-wheel and it worked. Looking to see what needs to be done for th eohters.
Thanks. The update is for all 3 of them.
I tested all three and gave karma.
On Fri, 9 Aug 2019 at 11:32, Miro Hrončok mhroncok@redhat.com wrote:
On 09. 08. 19 16:49, Stephen John Smoogen wrote:
I have tested python2-wheel and it worked. Looking to see what needs to
be done
for th eohters.
Thanks. The update is for all 3 of them.
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@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...
On 09. 08. 19 17:38, Stephen John Smoogen wrote:
I tested all three and gave karma.
Thanks. I'll wait for the push and retire the old packages.
I hope everything will work as expected.
On Fri, 9 Aug 2019 17:39:45 +0200 Miro Hrončok mhroncok@redhat.com wrote:
On 09. 08. 19 17:38, Stephen John Smoogen wrote:
I tested all three and gave karma.
Thanks. I'll wait for the push and retire the old packages.
I hope everything will work as expected.
I noticed a issue, python-pip-epel can't be build on up to date 7.7 system because python3_other srpm related macros are not provided by any package. I guess python-epel-rpm-macros package should provide python3-other-srpm-macros for python34 related bits. And these two new packages python3-other-srpm-macros and python3-other-rpm-macros should be added as dependency to epel-rpm-macros.
Issue caused by missing packages is %python3_other_pkgversion is unset, in mock log:
DEBUG util.py:587: Error: No Package found for python%{python3_other_pkgversion}-devel DEBUG util.py:587: Error: No Package found for python%{python3_other_pkgversion}-setuptools
On 11. 08. 19 20:41, Tuomo Soini wrote:
On Fri, 9 Aug 2019 17:39:45 +0200 Miro Hrončok mhroncok@redhat.com wrote:
On 09. 08. 19 17:38, Stephen John Smoogen wrote:
I tested all three and gave karma.
Thanks. I'll wait for the push and retire the old packages.
I hope everything will work as expected.
I noticed a issue, python-pip-epel can't be build on up to date 7.7 system because python3_other srpm related macros are not provided by any package. I guess python-epel-rpm-macros package should provide python3-other-srpm-macros for python34 related bits. And these two new packages python3-other-srpm-macros and python3-other-rpm-macros should be added as dependency to epel-rpm-macros.
There is python-epel-rpm-macros source package in EPEL now. It builds the python3-other-rpm-macros package.
python34-devel requires python3-other-rpm-macros.
epel-rpm-macros requires python-srpm-macros.
python-srpm-macros form RHEL 7.7+ indeed don't have this bit:
%python3_other_pkgversion 34
I believe the easiest fix is to define that directly in epel-rpm-macros:
https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5
Thanks for the report!
On Sun, 11 Aug 2019 22:26:45 +0200 Miro Hrončok mhroncok@redhat.com wrote:
%python3_other_pkgversion 34
I believe the easiest fix is to define that directly in epel-rpm-macros:
https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5
Correct. That fixes this issue but not the huge issue we have now.
Thanks for the report!
I agree. But we have much bigger problem with epel python naming.
python3_other is now defined to 3 in rhel7.7.
Because epel is supposed to add packages to rhel, we have now new definition which is our master. That means with 7.7 system and mock, there is no possibility to build python36 packages any more.
Because rhel selected python3 naming when inroduced python3 that gives epel7 new baseline for naming standard for python3 packages which means we should now follow that on epel7 post rhel7.7. Before python3 was added to rhel we could play with python3x naming freely but not any more.
We have two choises really, this suggestion of mine is based on the expectation that rhel7 continues to have more python3 packages in future with naming python3-<modname>.
Let's list some history, please notify if I forgot something important.
python3 packages were introduced to epel with python3x naming originally, and unlike fedora naming, python3 was replaced on every package with %python3_pkgversion and related macros. When python 3.6 was introduced to epel7 there was new macro %python3_other_pkgversion and related to that macros added.
When python 3.4 got EOL, macros were switched and python36 naming was set for %python3_pkgversion
rhel7.7 introduced python3 with fedora style python3 naming and %python3_pkgversion set to 3.
Now systems using new python-rpm-macros from rhel7.7 can't any more build any python3 package because all dependencies switch from python36-<modname> to python3-<modname> so package builds will fail inside mock. Because of koji still using old python*rpm-macros this is not yet visible on fedora build system but I tested and verified this with mock. Also these new macros cause all new python packages to be named python3-<modname>.
There are two possibilities how to handle this:
Introduce conflicting %python3_pkgversion (and other related macros) with 36 and 3.6 etc in them.
This would cause pain in every occasion when there is new python3 package added to rhel7 because rhel7 uses different naming. That would mean we would need to manually patch dependencies on packages in rhel7 because we don't have any guarantee that rhel packagers remember epel when doing rhel packages. So we need to manually change dependencies to rhel packages to be python3, not python%{python3_pkgversion}.
My suggestion for this is to do big python3 rebuild again in epel7, this time with python3_pkgversion from rhel7.7 and move clearly to rhel7.7 python3 naming and obsolete pythn34 now, people have already been notified that python34 is end of the life and not supported by upstream.
Add epel specific python_provide macro which for python3-modname does: normal provides as it did before.
Provides: python3-<modname> = %{version}-%{release} Obsoletes: python36-<modname> < %{version}-%{release} Obsoletes: python34-<modname> < %{version}-%{release}
Remove python3_other from epel7.
Only downside from this is that python3-modname source rpm naming won't work any more because rpm doesn't allow python3-modname naming in sub-package. My suggestion for that is to name these epel only source packages with python3-epel-modname or python3-modname-epel naming so that they can generate python3-modname.
On 12. 08. 19 8:14, Tuomo Soini wrote:
On Sun, 11 Aug 2019 22:26:45 +0200 Miro Hrončok mhroncok@redhat.com wrote:
%python3_other_pkgversion 34
I believe the easiest fix is to define that directly in epel-rpm-macros:
https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5
Correct. That fixes this issue but not the huge issue we have now.
Thanks for the report!
I agree. But we have much bigger problem with epel python naming.
python3_other is now defined to 3 in rhel7.7.
By what? Do you mean python3_pkgversion? W can override that as well.
Because epel is supposed to add packages to rhel, we have now new definition which is our master. That means with 7.7 system and mock, there is no possibility to build python36 packages any more.
Because rhel selected python3 naming when inroduced python3 that gives epel7 new baseline for naming standard for python3 packages which means we should now follow that on epel7 post rhel7.7. Before python3 was added to rhel we could play with python3x naming freely but not any more.
We have two choises really, this suggestion of mine is based on the expectation that rhel7 continues to have more python3 packages in future with naming python3-<modname>.
Let's list some history, please notify if I forgot something important.
python3 packages were introduced to epel with python3x naming originally, and unlike fedora naming, python3 was replaced on every package with %python3_pkgversion and related macros. When python 3.6 was introduced to epel7 there was new macro %python3_other_pkgversion and related to that macros added.
When python 3.4 got EOL, macros were switched and python36 naming was set for %python3_pkgversion
rhel7.7 introduced python3 with fedora style python3 naming and %python3_pkgversion set to 3.
Now systems using new python-rpm-macros from rhel7.7 can't any more build any python3 package because all dependencies switch from python36-<modname> to python3-<modname> so package builds will fail inside mock. Because of koji still using old python*rpm-macros this is not yet visible on fedora build system but I tested and verified this with mock. Also these new macros cause all new python packages to be named python3-<modname>.
There are two possibilities how to handle this:
Introduce conflicting %python3_pkgversion (and other related macros) with 36 and 3.6 etc in them.
Let's do that as a quick hotfix for now decide the rest later.
On 12. 08. 19 10:52, Miro Hrončok wrote:
On 12. 08. 19 8:14, Tuomo Soini wrote:
On Sun, 11 Aug 2019 22:26:45 +0200 Miro Hrončok mhroncok@redhat.com wrote:
%python3_other_pkgversion 34
I believe the easiest fix is to define that directly in epel-rpm-macros:
https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5
Correct. That fixes this issue but not the huge issue we have now.
Thanks for the report!
I agree. But we have much bigger problem with epel python naming.
python3_other is now defined to 3 in rhel7.7.
By what? Do you mean python3_pkgversion? W can override that as well.
Because epel is supposed to add packages to rhel, we have now new definition which is our master. That means with 7.7 system and mock, there is no possibility to build python36 packages any more.
Because rhel selected python3 naming when inroduced python3 that gives epel7 new baseline for naming standard for python3 packages which means we should now follow that on epel7 post rhel7.7. Before python3 was added to rhel we could play with python3x naming freely but not any more.
We have two choises really, this suggestion of mine is based on the expectation that rhel7 continues to have more python3 packages in future with naming python3-<modname>.
Let's list some history, please notify if I forgot something important.
python3 packages were introduced to epel with python3x naming originally, and unlike fedora naming, python3 was replaced on every package with %python3_pkgversion and related macros. When python 3.6 was introduced to epel7 there was new macro %python3_other_pkgversion and related to that macros added.
When python 3.4 got EOL, macros were switched and python36 naming was set for %python3_pkgversion
rhel7.7 introduced python3 with fedora style python3 naming and %python3_pkgversion set to 3.
Now systems using new python-rpm-macros from rhel7.7 can't any more build any python3 package because all dependencies switch from python36-<modname> to python3-<modname> so package builds will fail inside mock. Because of koji still using old python*rpm-macros this is not yet visible on fedora build system but I tested and verified this with mock. Also these new macros cause all new python packages to be named python3-<modname>.
There are two possibilities how to handle this:
Introduce conflicting %python3_pkgversion (and other related macros) with 36 and 3.6 etc in them.
Let's do that as a quick hotfix for now decide the rest later.
Updated https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5
Please some EPEL people, review and possibly build soon.
On Mon, 12 Aug 2019 10:52:34 +0200 Miro Hrončok mhroncok@redhat.com wrote:
python3_other is now defined to 3 in rhel7.7.
By what? Do you mean python3_pkgversion? W can override that as well.
Sorry. python3_pkgversion.
epel-devel@lists.fedoraproject.org
-
Jason L Tibbitts III -
Miro Hrončok -
Stephen John Smoogen -
Toshio Kuratomi -
Tuomo Soini