Description of problem: Upgraded Fedora from 32 to 33, my default command line (git) editor got changed to nano. Version-Release number of selected component (if applicable): Fedora 33 How reproducible: Happened on my two computers Steps to Reproduce: 1. Install Fedora 32 2. Upgrade using dnf to 33 Actual results: default editor changed from vi to nano Expected results: vi remains as a default editor Additional info: This page states there would be no changes to upgrades: https://fedoraproject.org/wiki/Changes/UseNanoByDefault - seems like a regression bug. Personal note: the above document says "Let's make Fedora more approachable, by having a default editor that doesn't require specialist knowledge to use." - I respectfully disagree, I have no idea how to use nano.
I can use both and I fully understand why "vi" will no longer be the default. There are memes about editors that are hard to even quit from. I stand behind that change, which followed the right change proposal path. I would find bug valid only if you already configured a preferred editor and that setting would have being lost during the upgrade.
Do you have the nano-default-editor package installed?
(In reply to Sorin Sbarnea from comment #1) > I can use both and I fully understand why "vi" will no longer be the > default. There are memes about editors that are hard to even quit from. > > I stand behind that change, which followed the right change proposal path. > > I would find bug valid only if you already configured a preferred editor and > that setting would have being lost during the upgrade. I'm not against the change, I'm reporting a bug in the way it was implemented. This is a change in behaviour after a dnf upgrade, it shouldn't happen. The change proposal says it should not affect upgrades, but it did. If someone didn't like vim, they would already set nano (or sth else) as their default editor. Those who are happy with vim would do nothing, since vim was used by default. Both scenarios don't need nano-default-editor package. The bug here is nano-default-editor package should not be installed on dnf upgrade, that's it. (In reply to Kamil Dudka from comment #2) > Do you have the nano-default-editor package installed? Yes it was installed. Uninstalling it solved the problem.
I cannot see any package that would require nano-default-editor. How exactly did you upgrade the system?
*** Bug 1900543 has been marked as a duplicate of this bug. ***
According to the following Fedora Change page: https://fedoraproject.org/wiki/Changes/UseNanoByDefault#Upgrade.2Fcompatibility_impact ... the change should not apply to upgrades. Now we have two bug reports saying it is not the case. Chris, could you please check what went wrong?
>2. Upgrade using dnf to 33 Was this using system-upgrade or distrosync?
Bug #1900543 comment #0 mentions system-upgrade.
I'm not sure how nano-default-editor could be brought in. It was tested during beta of course and this didn't come up. Maybe the dnf log of the upgrade can be used to infer the system state, create a Fedora 32 VM with that state, and then get debug logs when doing system-upgrade and see if it's possible catch the problem as it happens?
Default clean F32 Workstation -> updated -> and then do system-upgrade download... Installing group/module packages: fedora-repos-modular noarch 33-1 fedora 11 k nano-default-editor noarch 5.3-4.fc33 fedora 10 k opensc x86_64 0.20.0-7.fc33 fedora 1.2 M pt-sans-fonts noarch 20141121-18.fc33 fedora 930 k replacing paratype-pt-sans-fonts.noarch 20141121-10.fc32 thermald x86_64 2.3-2.fc33 fedora 223 k uresourced x86_64 0.3.0-1.fc33 fedora 41 k xorg-x11-drv-amdgpu x86_64 19.1.0-5.fc33 fedora 75 k zram-generator-defaults noarch 0.2.0-4.fc33 fedora 8.7 k replacing zram.noarch 0.4-1.fc32 It is being applied to upgrades. But I don't know why or what's changed. Maybe it's related to bug 1554010, which was updated ~7 days ago?
Added --debugsolver $ grep nano debugdata/rpms/solver.result install nano-default-editor-5.3-4.fc33.noarch@fedora upgrade nano-4.9.3-1.fc32.x86_64@@System nano-5.3-4.fc33.x86_64@fedora Complete debugdata (72M) is uploaded here: https://drive.google.com/file/d/1i2KtABchwHUmlPrPesF9-1hFDnnNna92/view?usp=sharing Just debugdata/rpms/updates.repo.gz (12M) is uploaded here: https://drive.google.com/file/d/1lRu1YaWO_hZhQcjv4vqvm2bHgb1euc2a/view?usp=sharing
dnf system-upgrade also upgrades groups, so nano-default-editor gets installed on system upgrades. This was added in dnf-plugins-extra 4.0.12.
markm: If you want to revert back to previous behavior, just "dnf remove nano-default-editor". Alternatively, you can set "export EDITOR=vim" in your ~/.bash_profile.
(In reply to Neal Gompa from comment #12) > dnf system-upgrade also upgrades groups, so nano-default-editor gets > installed on system upgrades. This was added in dnf-plugins-extra 4.0.12. I guess there's not really much we can do about this. The promise that the default editor will not change on upgrades was based on the assumption that dnf would continue to not upgrade comps groups, i.e. it assumed that upgrades would miss newly-added packages, as has historically been the case. But we've been arguing for a long time that this should change, and started developing strange workarounds each time we add new packages. So it's a very good change, even though it breaks this upgrade plan. It's a little annoying for the default terminal editor to change during upgrades, but I don't see any spectacular ways to avoid it other than to manually remove the package.
(In reply to Neal Gompa from comment #12) > dnf system-upgrade also upgrades groups, so nano-default-editor gets > installed on system upgrades. This was added in dnf-plugins-extra 4.0.12. This breaks the plan that comment #6 refers to. I do not think we should introduce such changes into already released versions of Fedora. Even more when they break promises we gave users long time before the release went out.
Wouldn't it be time to introduce a kind of news service when upgrading packages which introduce a breaking change? IIRC Debian has something like this: each package (or here group) owner could document their breaking change and it would appear to the user before the upgrade actually takes place, with information on what is changing, why, how to get back the old state, etc... It could be implemented similar to new GPG keys being acknowledged/accepted, it would just be new features instead.
Slightly off topic but yes, Gentoo Linux has also been using such a solution for 15 years or so: https://www.gentoo.org/glep/glep-0042.html
I don't think this is a dnf bug. Reverting this behavior would reintroduce tons of woes for distro upgrades. We don't want to go back to the dark ages where each new package needs a custom upgrade plan. It's just an oversight of the design of the change proposal. And there's not much we could do to catch it because at the time we tested the upgrade, dnf was not upgrading groups.
I agree with Michael on this, and I'd rather just go ahead and close this out.
I think the correct approach is to make the dnf change a properly announced/tested Fedora 34 change.
I do understand the problem that was caused by resolvent of issue https://bugzilla.redhat.com/show_bug.cgi?id=1860408. It means that one Fedora change required change in behaviour of system-upgrade and ASAP because the change already landed and breaks some user cases (fedora-repos-modular removed by `dnf autoremove`). Then there is other change in Fedora (https://fedoraproject.org/wiki/Changes/UseNanoByDefault#Upgrade.2Fcompatibility_impact) that requires formal behaviour of `system-upgrade`. I am really sorry but we cannot deliver both. From DNF side we have have no other choice than to close it as cantfix. What can be done is related to FESCO - change approvals od Fedora changes, or expectations from changes.
What information is required from me here? If you want the behavior to be: "Users who upgrade from Fedora 31/32 to Fedora 33 will have vim as the default and users who install will have nano as the default", I guess it can be achieved by clever obsoletes in order to upgrade f31/f32 vim to vim+vim-default-editor. That said, I'm not sure how would the bz1860408 fix respond to that fact that some of the group package conflicts with what should otherwise be installed. Jaroslav, do you know what happens if the resolver brings in vim-default-editor but the group tries to bring in nano-default-editor?
[liveuser@localhost-live ~]$ sudo dnf group install standard ... [liveuser@localhost-live ~]$ sudo dnf swap nano-default-editor vim-default-editor ... [liveuser@localhost-live ~]$ sudo dnf group upgrade standard ... This seem to work juts fine. I don't know how to confirm the upgrade thing thou :/ Anyway, this might be fixed by recommending vim-default-editor from vim on Fedora 32. It might even be fixed by recommending vim-default-editor from vim on anything newer.
Thanks Miro for your comments. I suggest that making a clever obsoletes or using a weakdeps doesn't make much sense or it is against the original proposal in https://fedoraproject.org/wiki/Changes/UseNanoByDefault#Upgrade.2Fcompatibility_impact. > What information is required from me here? The question why I brought you into conversation is simple. The change you requested to resolve one Fedora change brakes `Upgrade/compatibility impact` of another approved FESCO change. I ask you as FESCO member to fix the proposals to be not in conflict or provide a statement. In case that the conflict will be not resolved, we can suggest that FESCO change tickets is something like a recommendation that can be ignored.
> I suggest that making a clever obsoletes or using a weakdeps doesn't make much sense or it is against the original proposal in https://fedoraproject.org/wiki/Changes/UseNanoByDefault#Upgrade.2Fcompatibility_impact. I've proposed a possible fix in a way that aligns with the proposal and you say it doesn't make sense. Why doesn't it? How does it go against the proposal? Could you elaborate on that and actually answer my technical question wrt the system upgrade behavior instead of dismissing it right away? I understand that "will not apply to upgrades" means that users of Fedora 31/32 who upgrade to 33+ keep vim as the default. Let's work on that? > The question why I brought you into conversation is simple. The change you requested to resolve one Fedora change brakes `Upgrade/compatibility impact` of another approved FESCO change. I ask you as FESCO member to fix the proposals to be not in conflict or provide a statement. In case that the conflict will be not resolved, we can suggest that FESCO change tickets is something like a recommendation that can be ignored. Not really. The solution *you provided* fixed my problem but introduced a new one. IIRC I've asked to mark modular-repos as installed on upgrades, not to install new packages on upgrades. Anyway, here we are, we have a conflict and we should work together to a find a solution. I am trying to do that here. I think asking for FESCo statements or calling approved change proposals recommendation is a bit pre-mature. But if you really feel FESCo's input is necessary here, because we've exhausted all other options, you can open a ticket at https://pagure.io/fesco/issues -- may position is however, that we should try to solve this first.
I've also started this thread on devel: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6VZUYS6DMB455IYNCWEMFKMREGNK2WUZ/
(In reply to Miro Hrončok from comment #26) > I've also started this thread on devel: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6VZUYS6DMB455IYNCWEMFKMREGNK2WUZ/ As I read the discussion, people mostly do not care about nano-default-editor being installed on updates. Weak dependency hacks in vim/vim-default-editor might have unwanted side effects elsewhere. Let's close this bug as CANTFIX.
I've upgraded the section: https://fedoraproject.org/wiki/Changes/UseNanoByDefault#Upgrade.2Fcompatibility_impact (we can revert that edit if people fight back).
It makes sense to me. Thanks for the update!