Description of problem: 'dnf update' reports broken dependencies with django:1.6 and reviewboard:2.5 installed. Version-Release number of selected component (if applicable): dnf-2.7.5-12.fc28.noarch How reproducible: always Steps to Reproduce: 1. fresh container based on docker.io/fedora:28 (or other current F28 VM/container) with latest F28 updates and fedora-repos-modular enabled 2. dnf -y update # make sure everything is updated 3. dnf -y -q module install django:1.6 # module installed successfully 4. dnf update # nothing to do 5. dnf -y -q module install reviewboard:2.5 # module installed successfully 6. dnf update Actual results: Reports of broken dependencies. [root@9ec9629424de /]# dnf update Last metadata expiration check: 1:33:03 ago on Fri May 11 20:01:43 2018. Dependencies resolved. Problem 1: package python3-django-pipeline-1.6.8-6.fc28.noarch requires python3-django, but none of the providers can be installed - cannot install the best update candidate for package python2-django-pipeline-1.3.27-11.module_d032b812.noarch - nothing provides python-django-bash-completion = 2.0.5-1.fc28 needed by python3-django-2.0.5-1.fc28.noarch - nothing provides python-django-bash-completion = 2.0.4-1.fc28 needed by python3-django-2.0.4-1.fc28.noarch Problem 2: package python3-django-haystack-2.5.0-5.fc28.noarch requires python3-django, but none of the providers can be installed - cannot install the best update candidate for package python2-django-haystack-2.4.1-12.module_d032b812.noarch - nothing provides python-django-bash-completion = 2.0.5-1.fc28 needed by python3-django-2.0.5-1.fc28.noarch - nothing provides python-django-bash-completion = 2.0.4-1.fc28 needed by python3-django-2.0.4-1.fc28.noarch ================================================================================ Package Arch Version Repository Size ================================================================================ Skipping packages with broken dependencies: python3-django noarch 2.0.4-1.fc28 fedora 4.3 M python3-django noarch 2.0.5-1.fc28 updates-testing 4.3 M python3-django-haystack noarch 2.5.0-5.fc28 fedora 169 k python3-django-pipeline noarch 1.6.8-6.fc28 fedora 64 k Transaction Summary ================================================================================ Skip 4 Packages Nothing to do. Complete! [root@9ec9629424de /]# Expected results: "Nothing to do", with no reports of broken dependencies. Additional info:
This is not a DNF issue, the problem is in packaging. $ dnf repoquery python3-django-pipeline --obsoletes python-django-pipeline < 1.6.8-5 python2-django-pipeline < 1.6.8-5 $ dnf repoquery python3-django-haystack --obsoletes python-django-haystack < 2.5.0-5 python2-django-haystack < 2.5.0-5 These try to replace python2* django packages, but main python3-django is not available in module or hybrid repo.
IIRC, reviewboard is not compatible with Django-2.0. Django-1.6 (the only compatible version to support Reviewboard) was provided by modules. It looks like modules using older versions of a software should not pull that software from traditional fedora repos. Maybe a priority would help here? More context around the Django-2.0 change for f28: https://fedoraproject.org/wiki/Changes/Django20
This is something DNF can fix, really. Assigning to distribution to make a decision about the contents.
I mean't *can't* fix :)
(In reply to Daniel Mach from comment #4) > This is something DNF can fix, really. > Assigning to distribution to make a decision about the contents. Incorrect. This is a dupe of #1579350 which identifies that DNF's solver isn't handling default-vs-enabled correctly. *** This bug has been marked as a duplicate of bug 1579350 ***
Actually, this may not be exactly the same bug. Setting back to NEW for the moment while I investigate.
OK, I misread the problem. Daniel is correct in comment #2 that the bug is that pipeline and haystack are obsoleting the python2 package with a python3 package, which is completely unacceptable since they aren't suitable replacements.
I suppose the main issue here is that packages removed from the distribution are being added back without checking whether they are obsoleted by something or not. I mean, we can certainly remove that obsolete (although it was added via FESCo approved change) and add it to fedora-obsolete-packages as https://pagure.io/packaging-committee/issue/754 suggests, yet does it solve the problem?
(In reply to Miro Hrončok from comment #9) > I suppose the main issue here is that packages removed from the distribution > are being added back without checking whether they are obsoleted by > something or not. > The ReviewBoard module existed long before this Obsoletes was added. Adding the Obsoletes without checking what might rely on the python2 package was unfortunate. > I mean, we can certainly remove that obsolete (although it was added via > FESCo approved change) and add it to fedora-obsolete-packages as > https://pagure.io/packaging-committee/issue/754 suggests, yet does it solve > the problem? Can you point to that FESCo-approved change? I don't recall voting in favor of such an action. And no, adding it to fedora-obsolete-packages does not resolve the issue, because that's still going to attempt to remove the module package. Why is this desirable? Why is it necessary to remove these packages from an end-user's system if they still have the python2 interpreter around? And if *that* gets removed, these would all go with it anyhow.
Not obsoleting python2-django-pipeline from any package will result in broken update. python2-django-pipeline (from F27) requires python2-django. python2-django (from F27) requires a specific version of python-django-bash-completion as does python3-django - this will prevent python3-django update unless --allowerasing is set. (Note that this is currently not true, because python2-django (from F27) doesn't require python-django-bash-completion as all, but that is only a packaging bug I've just noticed and reported as bz1580517.)
(In reply to Stephen Gallagher from comment #10) > > I mean, we can certainly remove that obsolete (although it was added via > > FESCo approved change) and add it to fedora-obsolete-packages as > > https://pagure.io/packaging-committee/issue/754 suggests, yet does it solve > > the problem? > > Can you point to that FESCo-approved change? I don't recall voting in favor > of such an action. I think this is the version that got approved by FESCo: https://fedoraproject.org/w/index.php?title=Changes/Django20&oldid=509362 This is when it got Ready for FESCo: https://fedoraproject.org/w/index.php?title=Changes/Django20&oldid=508509 And this when it got ready for the wrangler: https://fedoraproject.org/w/index.php?title=Changes/Django20&oldid=507490 It actually contains a typo (Obosletes instead of Obsoletes), however the formation was there all the time in Scope. The python2-django-pipeline returned in module in https://src.fedoraproject.org/rpms/python-django-pipeline/c/42fb4b0fe697f0244bd27101293e07677ec25087?branch=1.6 i.e. couple of days after the Django change was approved by FESCo. I suppose as a reaction from your side.
(In reply to Miro Hrončok from comment #11) > Not obsoleting python2-django-pipeline from any package will result in > broken update. > > python2-django-pipeline (from F27) requires python2-django. > > python2-django (from F27) requires a specific version of > python-django-bash-completion as does python3-django - this will prevent > python3-django update unless --allowerasing is set. > Do you mean if python2-django and python3-django are installed at the same time? It might just be time to start making them Conflicts: Or do you mean that python3-django should Obsoletes: python2-django? I fundamentally disagree with this idea. > (Note that this is currently not true, because python2-django (from F27) > doesn't require python-django-bash-completion as all, but that is only a > packaging bug I've just noticed and reported as bz1580517.) Yeah, I saw the patch come through.
(In reply to Stephen Gallagher from comment #13) > Do you mean if python2-django and python3-django are installed at the same > time? Yes. > It might just be time to start making them Conflicts: Why would they need to conflict? > Or do you mean that python3-django should Obsoletes: python2-django? I > fundamentally disagree with this idea. I actually think that this should happen once (if) we remove retire python2, however obsoleting it trough fedora-obsolete-packages is fine with me. But I have never brought this to this discussion. Currently, python2-django1.11 obsoletes python2-django as per the Django 2.0 change.
(In reply to Miro Hrončok from comment #14) > (In reply to Stephen Gallagher from comment #13) > > Do you mean if python2-django and python3-django are installed at the same > > time? > > Yes. > > > It might just be time to start making them Conflicts: > > Why would they need to conflict? Well, if they can't be installed at the same time, they can't fight over the bash completions. > > > Or do you mean that python3-django should Obsoletes: python2-django? I > > fundamentally disagree with this idea. > > I actually think that this should happen once (if) we remove retire python2, > however obsoleting it trough fedora-obsolete-packages is fine with me. > > But I have never brought this to this discussion. Currently, > python2-django1.11 obsoletes python2-django as per the Django 2.0 change. Sure, and that was a reasonable thing to do from your end. I worked around that in my python2-django package by having it Obsolete python2-django1.11 if that repo was enabled. It wasn't supposed to have shipped as a "default stream", which is causing a bunch of problems; I've fixed that for F29. I'm going to see what we can do about it in F28 as well. However, it was the later Obsoletes of pipeline and haystack that have suddenly made this an issue, and I really don't understand why this wouldn't all just be solved by eventually having python2 be obsoleted by fedora-obsolete-packages once it's ultimately retired.
Note that we seek for a solution that ensures: * clean upgrade path from F26/F27 to F28 * making the module with python2-django 1.6 work Since python3-django-pipeline obsoletes python2-django-pipeline < 1.6.8-5, I believe the solution to this problem is bumping the evr of the modular python2-django-pipeline package (either bumping the release if the version is >= 1.6.8, or bumping the epoch if it is < 1.6.8). (In reply to Stephen Gallagher from comment #15) > However, it was the later Obsoletes of pipeline and haystack that have > suddenly made this an issue, You are right. Sorry about breaking stuff, however I wasn't aware we are not supposed to do this, as I was only following the approved change. > and I really don't understand why this wouldn't > all just be solved by eventually having python2 be obsoleted by > fedora-obsolete-packages once it's ultimately retired. This needs to be solved now, not once (and if) python2 is retired. The obsoletes were added to ensure clean upgrade path. And as said, I'd happily move them to fedora-obsolete-packages, but that wouldn't solve this at all.
An option I just thought of: I could opt to change my packages from python2-django-pipeline to python2-reviewboard-pipeline and add a Conflicts: on python2-django-pipeline (and make ReviewBoard rely on the new package name). That would work around this specific set of issues, at least. Unfortunately, Review Board 2.5 relies on pipeline 1.3, so I either have to rename or epoch-bump to resolve that. Haystack could probably get away with just revving the release version though.
Or just bump the evr.
(In reply to Miro Hrončok from comment #18) > Or just bump the evr. Like I said, I'd have to epoch-bump, which seems less than ideal here.
I feel like renaming is even less ideal. But that's most likely a subjective opinion.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.