On Wed, Oct 16, 2019 at 9:14 PM Rahul Sundaram <methe...@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. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
