#565 new python package guidelines create upgrade path problem from old guidelines
Closed: Fixed None Opened 4 years ago by dshea.

The new packaging guidelines rename python-foo to python2-foo without an Obsoletes, and the Provides for python-foo does not seem to be sufficient for an upgrade path.

As an example, I was attempting to update python-requests-file. The current spec file is at http://pkgs.fedoraproject.org/cgit/python-requests-file.git/tree/python-requests-file.spec, version 1.3.1-2. This file creates two binary packages, python-requests-file and python3-requests-file.

I updated to 1.4 and changed the spec file using the new template in the packaging guidelines, resulting in https://dshea.fedorapeople.org/python-requests-file.spec. This creates the packages python2-requests-file and python3-requests-file, and the python2-requests-file package provides python-requests-file = 1.4-1.fc24. However, when I add the 1.4 packages to a local repo and do a dnf upgrade, only the python3 package is selected for upgrade.

What is the correct thing to do? Should I add an Obsolete/Provides for python-requests-file to the python2 subpackage? What effect would that have when python3 becomes the default? And how should the guidelines reflect this?


This is a fine mess, I think. Not sure what the proper solution is.

It should be possible for the existing macros to emit an Obsoletes: along with the proper provides, but I honestly have no idea what happens when upstream Python decides to switch /usr/bin/python to py3. I'm thinking that what we should do is fix the macro to emit the Obsoletes, then after two releases simply change the macros to not emit the Obsoletes. I seriously doubt the py3 switch will happen before then.

Would like to see what the Python folks think, and also from someone who fully understands why the Obsoletes: is needed.

Obsoletes drive the replacement, that's the critical piece. The provides is just for naming compatibility for dependency requests.

Ideally you would:

Obsolete: python-requests-file < 1.3.1-3

So I'm not sure putting it in the macro makes the most sense.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-08-27/fpc.2015-08-27-16.05.txt):

  • 565 New python package guidelines create upgrade path problem from


    old guidelines (geppetto, 16:10:21)
  • LINK: https://fedorahosted.org/fpc/ticket/565 (geppetto, 16:10:21)
  • ACTION: Automatically add obsoletes for < provides version, in
    python_provides macro. (+1:6, 0:0, -1:0) (geppetto, 16:45:34)

I'm pretty sure this was done some time ago.

Well, it seems that it was done, but it was not documented. https://fedoraproject.org/wiki/Packaging:Python does not explain this new auto-obsolete behaviour at all, so we (me and kparal) were rather confused when we encountered it! Can whoever implemented this please update that page to document it? I'd do it, but I think it's better that someone who's familiar with the details of the implementation does it, I might write the wrong thing.

+1 It seems that it was done, (I just test it in F23) but it was not documented in https://fedoraproject.org/wiki/Packaging:Python

Just need add one line to wikipage, saying that "python_provides macro automatically add obsoletes for < provides version"

Reopen it, to request not get lost, I hope is the correct way of do it, if not please close the ticket again.

Thanks.

Metadata Update from @tibbs:
- Issue assigned to tibbs

2 years ago

Announcement text:

The section on the %python_provide macro in the Python guidelines now documents the situation where the macro will generate an Obsoletes:.

Login to comment on this ticket.

Metadata