Hi,
Currently, `dnf install python-package` will give you the Python 2 version. But, as you might know, upstream support for Python 2 will end in 2020. Around that time (or earlier), we'd like to make "python" mean Python 3 in Fedora. Before we do that switch, we need to stop using unqualified "python" in package names, and instead use either "python2" or "python3" everywhere.
Current packaging guidelines encourage packagers to do the right thing (see below for details). But it's not required, and many old packages use names that assume "python" means "Python 2".
What should we do? Should we mass fill bugs asking the packagers nicely to follow the new guidelines, or should we make a policy about this first and have the mass filled bugs backed up by it?
Technical details:
The current Python packaging guidelines [0] are written in a way that new packages will most likely be created in the following pattern:
SRPM: python-modulename built packages: python2-modulename (providing python-modulename via %python_provide) python3-modulename (not yet providing python-modulename via %python_provide)
The %python_provide is there to easily transfer to the following state:
SRPM: python-modulename built packages: python2-modulename (not anymore providing python-modulename via %python_provide) python3-modulename (providing python-modulename via %python_provide)
In order to make the switch, we would need all the Python packages in this state. However, there are plenty of other scenarios:
SRPM: python-modulename built packages: python-modulename (without %python_provide) python3-modulename (without %python_provide)
or
SRPM: python-modulename built packages: python-modulename (without %python_provide) (without python3 at all)
or even
SRPM: pymodulename built packages: pymodulename (without %python_provide) python3-modulename, python3-pymodulename or even py3modulename (without %python_provide)
We've started tracking the state on PortingDB [1].
[0] https://fedoraproject.org/wiki/Packaging:Python [1] http://fedora.portingdb.xyz/namingpolicy/
Thanks for help, Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
On 04/19/2017 05:17 AM, Miro Hrončok wrote:
Hi,
Currently, `dnf install python-package` will give you the Python 2 version. But, as you might know, upstream support for Python 2 will end in 2020. Around that time (or earlier), we'd like to make "python" mean Python 3 in Fedora. Before we do that switch, we need to stop using unqualified "python" in package names, and instead use either "python2" or "python3" everywhere.
Current packaging guidelines encourage packagers to do the right thing (see below for details). But it's not required, and many old packages use names that assume "python" means "Python 2".
What should we do? Should we mass fill bugs asking the packagers nicely to follow the new guidelines, or should we make a policy about this first and have the mass filled bugs backed up by it?
Thank you for raising this issue, it's important. Having just completed some python packaging work for both Fedora and RHEL I can attest the current situation is a bit of a mess. There is inconsistency in Fedora over the use of the python-provide macro and there can be a fair amount of manual work trying to figure out what names should be used for dependencies.
Compounding the problem is the fact many maintainers have a desire to share the spec file between Fedora and RHEL for obvious reasons. The situation is far worse in RHEL-7, it's a hodgepodge of different names compounded by the lack of the same python macros being used in Fedora. Spec files have gotten really ugly and I'm worried about the number of "hacks" being added to spec files to compensate (i.e. copying macro definitions into the spec file so the same logic can be used in RHEL).
I realize this is a Fedora specific mailing list but we can't simply ignore the reality of how packaging is often shared between the two distributions.
After having experienced the pain involved due to the inconsistencies (both intra-Fedora and inter-Fedora) my vote would be to:
1) Define the exact rules and migration path.
2) Coordinate with RHEL.
3) File bugs and mandate the rules from #1 be followed and that all packages must comply within a well defined period.
On Wed, Apr 19, 2017 at 4:12 PM, John Dennis jdennis@redhat.com wrote:
On 04/19/2017 05:17 AM, Miro Hrončok wrote:
Hi,
Currently, `dnf install python-package` will give you the Python 2 version. But, as you might know, upstream support for Python 2 will end in 2020. Around that time (or earlier), we'd like to make "python" mean Python 3 in Fedora. Before we do that switch, we need to stop using unqualified "python" in package names, and instead use either "python2" or "python3" everywhere.
Current packaging guidelines encourage packagers to do the right thing (see below for details). But it's not required, and many old packages use names that assume "python" means "Python 2".
What should we do? Should we mass fill bugs asking the packagers nicely to follow the new guidelines, or should we make a policy about this first and have the mass filled bugs backed up by it?
Thank you for raising this issue, it's important. Having just completed some python packaging work for both Fedora and RHEL I can attest the current situation is a bit of a mess. There is inconsistency in Fedora over the use of the python-provide macro and there can be a fair amount of manual work trying to figure out what names should be used for dependencies.
Compounding the problem is the fact many maintainers have a desire to share the spec file between Fedora and RHEL for obvious reasons. The situation is far worse in RHEL-7, it's a hodgepodge of different names compounded by the lack of the same python macros being used in Fedora. Spec files have gotten really ugly and I'm worried about the number of "hacks" being added to spec files to compensate (i.e. copying macro definitions into the spec file so the same logic can be used in RHEL).
I realize this is a Fedora specific mailing list but we can't simply ignore the reality of how packaging is often shared between the two distributions.
After having experienced the pain involved due to the inconsistencies (both intra-Fedora and inter-Fedora) my vote would be to:
Define the exact rules and migration path.
Coordinate with RHEL.
and EPEL.
3) File bugs and mandate the rules from #1 be followed and that all
packages must comply within a well defined period.
This won't be a one step process. Even if one day I follow the guideline, on my next package update I don't read the guideline and create a non-compliant package.
4) create scripts which automatically check whether the policy is followed and open bugs.
Marcin
-- John
packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
On 19.4.2017 16:21, Marcin Dulak wrote:
On Wed, Apr 19, 2017 at 4:12 PM, John Dennis <jdennis@redhat.com mailto:jdennis@redhat.com> wrote:
On 04/19/2017 05:17 AM, Miro Hrončok wrote: Hi, Currently, `dnf install python-package` will give you the Python 2 version. But, as you might know, upstream support for Python 2 will end in 2020. Around that time (or earlier), we'd like to make "python" mean Python 3 in Fedora. Before we do that switch, we need to stop using unqualified "python" in package names, and instead use either "python2" or "python3" everywhere. Current packaging guidelines encourage packagers to do the right thing (see below for details). But it's not required, and many old packages use names that assume "python" means "Python 2". What should we do? Should we mass fill bugs asking the packagers nicely to follow the new guidelines, or should we make a policy about this first and have the mass filled bugs backed up by it? Thank you for raising this issue, it's important. Having just completed some python packaging work for both Fedora and RHEL I can attest the current situation is a bit of a mess. There is inconsistency in Fedora over the use of the python-provide macro and there can be a fair amount of manual work trying to figure out what names should be used for dependencies. Compounding the problem is the fact many maintainers have a desire to share the spec file between Fedora and RHEL for obvious reasons. The situation is far worse in RHEL-7, it's a hodgepodge of different names compounded by the lack of the same python macros being used in Fedora. Spec files have gotten really ugly and I'm worried about the number of "hacks" being added to spec files to compensate (i.e. copying macro definitions into the spec file so the same logic can be used in RHEL). I realize this is a Fedora specific mailing list but we can't simply ignore the reality of how packaging is often shared between the two distributions. After having experienced the pain involved due to the inconsistencies (both intra-Fedora and inter-Fedora) my vote would be to: 1) Define the exact rules and migration path. 2) Coordinate with RHEL.and EPEL.
3) File bugs and mandate the rules from #1 be followed and that all packages must comply within a well defined period.This won't be a one step process. Even if one day I follow the guideline, on my next package update I don't read the guideline and create a non-compliant package.
- create scripts which automatically check whether the policy is
followed and open bugs.
Could be added to Taskotron.
Marcin
-- John _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org <mailto:packaging@lists.fedoraproject.org> To unsubscribe send an email to packaging-leave@lists.fedoraproject.org <mailto:packaging-leave@lists.fedoraproject.org>
I would argue here that it is more of maintenance burden, trying to keep a SPEC file synced between distros, than having a different SPEC for each branch.
There are even SPECs that use suse macros in order to keep the same SPEC pretty much everywhere, and while it might be an interesting work to do, I do not really see any advantages from the packager's POV.
In regards to RHEL packaging. At the next rhel 7 minor release, the fedora python packaging macros will be included, so that would help with some aspects of packaging for RHEL and EPEL.
What would you mean to coordinate with RHEL though?
Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat
----- Original Message ----- From: "John Dennis" jdennis@redhat.com To: "Discussion of RPM packaging standards and practices for Fedora" packaging@lists.fedoraproject.org, "Miro Hrončok" mhroncok@redhat.com Sent: Wednesday, April 19, 2017 4:12:14 PM Subject: [Fedora-packaging] Re: How to "enforce" new Python packaging Guidelines (for naming)
On 04/19/2017 05:17 AM, Miro Hrončok wrote:
Hi,
Currently, `dnf install python-package` will give you the Python 2 version. But, as you might know, upstream support for Python 2 will end in 2020. Around that time (or earlier), we'd like to make "python" mean Python 3 in Fedora. Before we do that switch, we need to stop using unqualified "python" in package names, and instead use either "python2" or "python3" everywhere.
Current packaging guidelines encourage packagers to do the right thing (see below for details). But it's not required, and many old packages use names that assume "python" means "Python 2".
What should we do? Should we mass fill bugs asking the packagers nicely to follow the new guidelines, or should we make a policy about this first and have the mass filled bugs backed up by it?
Thank you for raising this issue, it's important. Having just completed some python packaging work for both Fedora and RHEL I can attest the current situation is a bit of a mess. There is inconsistency in Fedora over the use of the python-provide macro and there can be a fair amount of manual work trying to figure out what names should be used for dependencies.
Compounding the problem is the fact many maintainers have a desire to share the spec file between Fedora and RHEL for obvious reasons. The situation is far worse in RHEL-7, it's a hodgepodge of different names compounded by the lack of the same python macros being used in Fedora. Spec files have gotten really ugly and I'm worried about the number of "hacks" being added to spec files to compensate (i.e. copying macro definitions into the spec file so the same logic can be used in RHEL).
I realize this is a Fedora specific mailing list but we can't simply ignore the reality of how packaging is often shared between the two distributions.
After having experienced the pain involved due to the inconsistencies (both intra-Fedora and inter-Fedora) my vote would be to:
1) Define the exact rules and migration path.
2) Coordinate with RHEL.
3) File bugs and mandate the rules from #1 be followed and that all packages must comply within a well defined period.
"CS" == Charalampos Stratakis cstratak@redhat.com writes:
CS> I would argue here that it is more of maintenance burden, trying to CS> keep a SPEC file synced between distros, than having a different CS> SPEC for each branch.
You might argue that, and I've been arguing it for years, but in the end the maintainer makes that decision.
CS> There are even SPECs that use suse macros in order to keep the same CS> SPEC pretty much everywhere,
That is forbidden in Fedora.
CS> and while it might be an interesting work to do, I do not really see CS> any advantages from the packager's POV.
Well, the "fedpkg switch-branch epel7; git merge master" workflow is rather convenient. It's hard to argue against that.
- J<
I would prefer that "python" by default means Python 3 ASAP (on all platforms if I had my way), and all packages requiring Python 2 should explicitly require Python 2, and use python2 binary. Whatever happens should be agreed on as a policy, clearly defining the intent of the community, and then we can evaluate the gaps. Then we can agree on strategies to bridge the gaps.
Maybe organize a hackathon at a PyCon to deal with the massive backlog of bugs and give the maintainers some code reviewed pull requests? There's a couple of PyCons between now and then, at least.
On Wed, Apr 19, 2017, 11:29 Jason L Tibbitts III tibbs@math.uh.edu wrote:
"CS" == Charalampos Stratakis cstratak@redhat.com writes:
CS> I would argue here that it is more of maintenance burden, trying to CS> keep a SPEC file synced between distros, than having a different CS> SPEC for each branch.
You might argue that, and I've been arguing it for years, but in the end the maintainer makes that decision.
CS> There are even SPECs that use suse macros in order to keep the same CS> SPEC pretty much everywhere,
That is forbidden in Fedora.
CS> and while it might be an interesting work to do, I do not really see CS> any advantages from the packager's POV.
Well, the "fedpkg switch-branch epel7; git merge master" workflow is rather convenient. It's hard to argue against that.
- J<
packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
packaging@lists.fedoraproject.org
-
Charalampos Stratakis -
Jason L Tibbitts III -
Jeremy McMillan -
John Dennis -
Marcin Dulak -
Miro Hrončok