On Wed, Oct 16, 2019 at 9:14 PM Rahul Sundaram <metherid(a)gmail.com> wrote:
Stephen Gallagher wrote:
>
>
> Currently, our default stance has been "disallow the system upgrade if
> the modules they've locked onto won't be available there". This is
> based on our philosophy that ultimately "the app is what matters".
> Most people don't install Linux because they enjoy clicking buttons in
> Anaconda. They install Linux because they have an application they
> want to deploy
You have to consider that not all applications are as important as keeping up with the
distribution lifecycle itself. If I have Fedora deployed in a bunch of places, I need to
be able to move to the next release which is supported if the current release I am running
is nearing EOL. At that point, if a module is orphaned and it happens to be a leaf
application (say the bat utility which is currently provided as a module and one I happen
to use), I don't really want it blocking my ability to upgrade. I would certain like
to be informed about the fact but I would want to get to the next release anyway.
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.