Hi
On Wed, Oct 16, 2019 at 9:21 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Wed, Oct 16, 2019 at 9:17 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
>
> On Wed, Oct 16, 2019 at 9:14 PM Rahul Sundaram <metherid@xxxxxxxxx> wrote:
> If that's the case, the most obvious way to inform you is to disallow
> the upgrade and have you resolve it by doing a `dnf module remove bat`
> and then rerunning the upgrade.
One could do that yes but it is helpful to have dnf essentially offer to do this an option
When "bat" was non-modular, we didn't require this. Why does it being
a module change this? The underlying RPMs still have their
dependencies satisfied. If they didn't, DNF would elect to offer its
removal as part of the upgrade after passing "--allowerasing". This
behavior is sane, useful, and understandable. I don't see a reason it
wouldn't map cleanly to modular content.
Indeed. Before --allowerasing was implemented by dnf and it gained the feature to suggest that users run it to workaround broken dependencies, one would manually be able to remove the dependencies and unbreak themselves out of that problem and upgrading using yum wiki page did prominently suggest that workaround. Allowerasing was a step up in usability however and I wouldn't want orphaned or broken modules to a hindrance to that. Again, in the case of bat, the underlying breakages was blocking updates for a while till I figured out the right steps. So this isn't merely a theoretical example either
Rahul
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
