#753 python2-... should not be packaged when it's not needed
Closed: accepted 4 years ago Opened 4 years ago by churchyard.

Link to the draft

First part of https://fedoraproject.org/wiki/Packaging:Python


Link to diff



Currently, packagers tend to automatically add both python3 and python2 subpackages without thinking. This should provide some ground for reviewers to ask: Is that legacy python2 part really needed?

I'm not sure I agree with this; it goes too far. As we've seen with static libraries, people package things because they have some use for them. If my local python2 application benefits from Fedora having python2 packages in the distribution then I don't see why Fedora should be trying to discourage me from packaging them.

The only analogous thing I can think of currently is static libraries, and we discourage those simply because it is difficult to track their use (since they won't appear as runtime dependencies). But you can certainly package them if you want.

The only thing relating to this issue that I do think should be in the guidelines is already in there: a statement that you may provide the python2 version, but are not required to do so.

Metadata Update from @tibbs:
- Issue tagged with: meeting

4 years ago

I think the reason behind is that Python guys are preparing for dropping Python 2 after its EOL.

However, there are 2 ways of doing that:

  • Manually ask people to stop doing that (what this ticket is about)
  • Improve packaging that way that it creates subpackages automatically so whenever Fedora decides to drop Python 2, we would just change python-rpm-macros (or any package like that) to not generate python2 subpackages anymore and we are done

Perhaps the current python maintainers intend to drop python2 once "official" python2 maintenance stops. But that says nothing about what others in the community will do with the successor projects which have already appeared to continue to support python2 code.

I don't think the packaging guidelines should be telling people not to package something just because one group doesn't want to support it, in the absence of some distro-wide policy decision which would ban anything which is capable of executing python2 code from remaining in or entering the distribution. The packaging guidelines are a good place to mention such a policy, but they are not the place to actually make that policy.

I see. Would a less strong change be considered? Bold for changed from original:

In Fedora we have multiple Python runtimes, one for each supported major Python release. At this point that's one for python3.x and one for python2.7. However the python2 stack will be removed in the foreseeable future. If a piece of software supports python3, it MUST be packaged for python3. If it supports python2 as well, it MAY be packaged for python2. If it supports only python2 then (obviously) it MUST NOT be packaged for python3, the packager SHOULD contact upstream and encourage them to correct this mistake.

I.e. there is one actual change (packager SHOULD contact upstream) and a bit of rewording. I have also capitalized MAY, MUST and MUST NOT (no bold there because I didn't change the wording).

This doesn't change the guidelines much, however it makes the python2 stack less important which it in fact is.

We discussed this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-03-01/fpc.2018-03-01-17.00.txt):

  • x753 python2-... should not be packaged when it's not needed
    (geppetto, 17:33:46)
  • ACTION: Change Packaging:Python to make it clear py2 is nearling
    upstream EOL and isn't required (+1:6, 0:0, -1:0) (geppetto,

Metadata Update from @james:
- Issue untagged with: meeting
- Issue tagged with: writeup

4 years ago

Announcement text:

A note was added to the Python guidelines indicating that the python2 stack may go away and that upstreams should be contacted about software not yet ported to python3.

Metadata Update from @tibbs:
- Issue untagged with: writeup
- Issue assigned to tibbs
- Issue tagged with: announce

4 years ago

Metadata Update from @tibbs:
- Issue untagged with: announce
- Issue close_status updated to: accepted
- Issue status updated to: Closed (was: Open)

4 years ago

Login to comment on this ticket.