Description of problem: Testing out the upgrade, I see: fedora-obsolete-packages noarch 30-36 updates-testing 53 k replacing python2-blockdiag.noarch 1.5.3-15.fc29 but I don't see python3-blockdiag being installed. This means that /usr/bin/blockdiag is no longer available (which is the reason I installed this package in the first place.) Version-Release number of selected component (if applicable): 1.5.3-15.fc29 and 1.5.4-1.fc30 Steps to Reproduce: $ docker run --rm -it fedora:29 /bin/bash # dnf install python2-blockdiag # dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync Actual results: python2-blockdiag is removed and nothing replaced /usr/bin/blockdiag Expected results: The blockdiag program is not removed.
I see, the python3-blockdiag package should replace somehow (obsolete and provide?) the python2-blockdiag package. This is tricky because while we are providing python modules in addition to programs in this package and the other related *diag packages. One way to solve this would be to produce a "blockdiag" sub-package with the relevant bits (program, manual etc) and have it require the python3-blockdiag package containing the python module. Any idea what the best course of action would be to make the upgrade path work? I will have to ponder this, thanks for catching that!
Miro might have a better idea of what's done for other Python 2->3 executables.
Providing a "blockdiag" package with the tool and manuals etc. is a good approach, but it won't fix your problem. Note that python2-blockdiag screams "python 2 module", not "an executable that is supposed to do some things", so yes, please do this. Once there is a "blockdiag" package, you should probably provide/obsolete python2-blockdiag from it (and remove the obsoleting bits from fedora-obsolete-packages)and conflict with python3-blockdiag < LAST_VERSION_WITH_THE_EXECUTABLE. That will solve you upgrade path. If you are looking for a quicker fix, obsoleting and providing python2-blockdiag from python3-blockdiag will do the trick.
Miro, would this change in f30 be enough if I don't split the f29 packages? %package -n %{srcname} Summary: %{summary} Requires: python3-%{srcname} = %{version}-%{release} Supplements: python2-%{srcname} Would a supplement work even though it is also obsoleted by fedora-obsolete-packages?
Why Supplements? What are you trying to accomplish?
In f29 python2-blockdiag contains both libraries and /usr/bin/blockdiag, so the idea is to move the program in a blockdiag package in f30 that replaces (or supplements) python2-blockdiag. This way the python2-blockdiag package could still be marked as obsolete, but offer an upgrade path to blockdiag in f30. Assuming that blockdiag users would primarily install python2-blockdiag for the program itself, they would still have it in f30 if Supplements: can work together with Obsoletes: (from fedora-obsolete-packages) in this scenario.
I've never seen supplements used to replace something and I don't think it works that way. I'd use obsoletes. We can remove the obsoletes from fedora-obsolete-packages.
I see, I will add this instead in f30 and rawhide: %package -n %{srcname} Summary: %{summary} Requires: python3-%{srcname} = %{version}-%{release} Obsoletes: python2-%{srcname} Provides: python2-%{srcname} And you can remove python2-{block,act,seq,nw}diag from fedora-obsolete-packages (the 3 other packages have the same problem). Conflicting with python3-%{srcname} < $F29_VERSION shouldn't be needed, there is already a strict Requires: field. Would you agree with this plan?
Please: Obsoletes: python2-%{srcname} < $F29_VERSION_RELEASE+1 Provides: python2-%{srcname} = %{version}-%{release}
Right, that wasn't explicitly said in your first message but I guess this is standard procedure from the guidelines. Duly noted. Those two specific lines can go away when f29 reaches its EOL, correct?
Usually there are kept for 3 releases, to support updates from the version that got the obsoleted package.
Let me know when both rawhide and F30 builds are ready, so I can do a joined F30 update.
The following packages were built f30: - python-actdiag-0.5.4-14.fc30 (https://koji.fedoraproject.org/koji/taskinfo?taskID=34307645) - python-blockdiag-1.5.4-4.fc30 (https://koji.fedoraproject.org/koji/taskinfo?taskID=34307649) - python-nwdiag-1.0.4-14.fc30 (https://koji.fedoraproject.org/koji/taskinfo?taskID=34307581) - python-seqdiag-0.9.6-2.fc30 (https://koji.fedoraproject.org/koji/taskinfo?taskID=34307611) Built in rawhide before f30.
python-seqdiag-0.9.6-2.fc30 python-nwdiag-1.0.4-14.fc30 python-blockdiag-1.5.4-4.fc30 python-actdiag-0.5.4-14.fc30 fedora-obsolete-packages-30-41 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-919e826bbe
fedora-obsolete-packages-30-41, python-actdiag-0.5.4-14.fc30, python-blockdiag-1.5.4-4.fc30, python-nwdiag-1.0.4-14.fc30, python-seqdiag-0.9.6-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-919e826bbe
fedora-obsolete-packages-30-41, python-actdiag-0.5.4-14.fc30, python-blockdiag-1.5.4-4.fc30, python-nwdiag-1.0.4-14.fc30, python-seqdiag-0.9.6-2.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.