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: > > > > > > 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. 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
