Bug 1577394 - [modularity] update operation reports broken dependencies
Summary: [modularity] update operation reports broken dependencies
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: python-django-pipeline
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Runge
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1478068
TreeView+ depends on / blocked
 
Reported: 2018-05-11 21:42 UTC by Merlin Mathesius
Modified: 2019-05-28 22:39 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-28 22:39:58 UTC


Attachments (Terms of Use)

Description Merlin Mathesius 2018-05-11 21:42:57 UTC
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:

Comment 2 Daniel Mach 2018-05-14 13:21:04 UTC
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.

Comment 3 Matthias Runge 2018-05-15 09:09:35 UTC
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

Comment 4 Daniel Mach 2018-05-21 11:09:49 UTC
This is something DNF can fix, really.
Assigning to distribution to make a decision about the contents.

Comment 5 Daniel Mach 2018-05-21 11:10:15 UTC
I mean't *can't* fix :)

Comment 6 Stephen Gallagher 2018-05-21 16:16:18 UTC
(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 ***

Comment 7 Stephen Gallagher 2018-05-21 16:18:16 UTC
Actually, this may not be exactly the same bug. Setting back to NEW for the moment while I investigate.

Comment 8 Stephen Gallagher 2018-05-21 16:31:13 UTC
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.

Comment 9 Miro Hrončok 2018-05-21 16:47:04 UTC
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?

Comment 10 Stephen Gallagher 2018-05-21 17:07:17 UTC
(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.

Comment 11 Miro Hrončok 2018-05-21 17:11:19 UTC
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.)

Comment 12 Miro Hrončok 2018-05-21 17:18:26 UTC
(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.

Comment 13 Stephen Gallagher 2018-05-21 17:29:33 UTC
(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.

Comment 14 Miro Hrončok 2018-05-21 17:44:15 UTC
(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.

Comment 15 Stephen Gallagher 2018-05-21 17:48:45 UTC
(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.

Comment 16 Miro Hrončok 2018-05-21 17:58:29 UTC
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.

Comment 17 Stephen Gallagher 2018-05-21 18:02:56 UTC
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.

Comment 18 Miro Hrončok 2018-05-21 18:34:06 UTC
Or just bump the evr.

Comment 19 Stephen Gallagher 2018-05-21 20:04:14 UTC
(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.

Comment 20 Miro Hrončok 2018-05-21 20:15:16 UTC
I feel like renaming is even less ideal. But that's most likely a subjective opinion.

Comment 21 Ben Cotton 2019-05-02 20:47:32 UTC
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.

Comment 22 Ben Cotton 2019-05-28 22:39:58 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.