OK, this is a special circumstance and one we didn't account for.

What happened here is that a new package was added to Fedora to be parallel-installable with python-django 2.x. This python2-django1.11 package added `Obsoletes: python2-django < 2` to itself, which is causing it to tell DNF "I should be used instead of any package calling itself python2-django with a version less than 2".

The bug here is that DNF's module handling doesn't handle the name change in this situation (it would be the same problem if we had just been going from python-django to python2-django). We probably need the depsolving logic to somehow figure out that because this package came from an enabled module, it's not eligible to be renamed unless the replacement is coming from another stream of the same module.

That all being said, I'd vote -1 to block on this for Beta and probably for Final because it really is an unlikely edge-case. The fact that it happened to hit one of our prototype modules is unfortunate, but it's mostly because the Django folks decided to carry a compat module instead of packaging it as a module stream.

Proposed as a Blocker for 28-beta by Fedora user sgallagh using the blocker tracking app because:

 FESCo identified a set of criteria that modularity was required to meet[1] in order for Fedora 28 Beta to ship. One of those requirements is that updating modules must use the available updates from the fedora-modular-updates[-testing] repos appropriately.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1537253#c6

I proposed this as a blocker because I think it needs the review of more people, but as I noted above I'm -1 to block Beta on this. The functionality works in most cases, which is the spirit of the criterion. This is an edge case, and certainly a bug we need to fix, but I don't know that we have to fix it *for Beta*. I'd entertain an argument to block Final on it though.

With Stephen's explanation, I think I'm -1 for Beta at least.

-1 beta blocker.

-1 Beta blocker but definitely something to look for F28 Final.

-1 on beta blocker/+1 on F28 Final

Oh, this is bad.  But +1 to the blocker suggestions.

This can be reproduced with the latest dnf, 2.7.5-9.fc28.

The behavior is expected and according to current specifications.
If DNF should behave differently, could anyone put together specs for the expected behavior?

(In reply to Daniel Mach from comment #10)
> The behavior is expected and according to current specifications.
> If DNF should behave differently, could anyone put together specs for the
> expected behavior?

I'm not sure I'd agree that it's expected (at least from a user perspective). There's an argument to be made here that there's a bug in our packaging policy that allowed this situation to occur, of course.

I think the additional specification is that Obsoletes: should be ignored that would cause a package in an enabled module to be superseded by a package from anywhere except another stream of that same module.

Now... poke holes in that until we find the right phrasing :)

-1 blocker for beta, but I'd like this resolved for final (either by changes to dnf or to packaging policy -- don't care).

For this *specific* module, I'm going to implement a workaround and just have the modular version explicitly Obsoletes the non-modular one. But we'll leave this ticket open for DNF to come up with a correct implementation down the road.

django-1.6-20180328170906.c2c572ec has been submitted as an update to Fedora 28 Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2018-0e193b5c1a

django-1.6-20180328170906.c2c572ec has been pushed to the Fedora 28 Modular 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-MODULAR-2018-0e193b5c1a

I tested this in a container that was pointed at a synchronized updates-testing repo tonight. The workaround appears to behave correctly for the Django module (it no longer offers to upgrade the 1.6 version from the module to the 1.11 version from the base repo).

(In reply to Daniel Mach from comment #10)
> The behavior is expected and according to current specifications.
> If DNF should behave differently, could anyone put together specs for the
> expected behavior?

Daniel, it sounds like we need a sticky vendor implementation in DNF to resolve this issue.

libsolv has the ability to filter updates based on "vendor", which is traditionally defined by repo ID. In this case, we'd probably want a second attribute from the repodata that can be used to indicate that it's the same "vendor", since we're not splitting modules into their own repositories.

Having a sticky vendor implementation would generally be useful for people who use third party repositories or COPRs to replace Fedora packages, too, so they don't get surprised with them getting switched randomly.

Discussed at 2018-03-29 go/no-go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting/2018-03-29/f28-beta-go-no-go-meeting.2018-03-29-16.04.html . Rejected as a Beta blocker on the grounds this is quite a corner case, and the known instance of it has been worked around for Beta: we don't think it's enough of a violation of the requirements in https://bugzilla.redhat.com/show_bug.cgi?id=1537253#c6 to constitute a blocker.

django-1.6-20180328170906.c2c572ec has been pushed to the Fedora 28 Modular stable repository. If problems still persist, please make note of it in this bug report.

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.

Stephen, would you say we still need DNF folks to look at doing something here?

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.

Sorry, I missed this in the flood of EOL notifications.

So, I do think that we should have some protection against this. We have a stated requirement that DNF should never attempt to upgrade from a modular package to a non-modular one (specifically for the case where the module metadata gets misplaced) and I think that basically applies here too.

DNF-4 modular filtering is based on the name search and on the provide search. In case of python2-django1.11 the issue would be resolved if python2-django1.11 will provide python2-django.

In case that we want to restrict upgrade using vendor, the approach must be verified by Modularity team and distribution itself => changing component.

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
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 '30'.

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 30 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 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 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.