Bug 1955884

I am not able to reproduce it on a fresh f33 VM with vim-default-editor-8.2.2811-1.fc33.noarch installed:

# yum install vim-default-editor
# exec bash -l
# echo $EDITOR
/usr/bin/vim

# dnf upgrade --refresh
# dnf install 'dnf-command(system-upgrade)'
# dnf system-upgrade download --releasever 34
# dnf system-upgrade reboot
[...]

# hostnamectl 
 Static hostname: ci-vm-10-0-137-55.hosted.upshift.rdu2.redhat.com
       Icon name: computer-vm
         Chassis: vm
      Machine ID: a5f18bd752c24d1d848e03a937c9bdf4
         Boot ID: 1aadfbc75f674224ad7d089746de59d8
  Virtualization: kvm
Operating System: Fedora 34 (Thirty Four)
     CPE OS Name: cpe:/o:fedoraproject:fedora:34
          Kernel: Linux 5.11.17-300.fc34.x86_64
    Architecture: x86-64
 Hardware Vendor: Red Hat
  Hardware Model: OpenStack Compute

# echo $EDITOR
/usr/bin/vim

Do we have any self-contained reproducer for this?

That's a difficult one because my Fedora has a bumpy history: it started as a KDE spin, was migrated to Cinnamon, and well...
I'll see what I can do.

It was probably easier than I thought, trying to see which packages I exactly have, I called the following:

```
$ sudo dnf group install cinnamon-desktop-environment
Last metadata expiration check: 0:42:36 ago on Mon 24 May 2021 06:16:15 CEST.
No match for group package "xorg-x11-drv-armsoc"
Error: 
 Problem: problem with installed package vim-default-editor-2:8.2.2875-1.fc34.noarch
  - package vim-default-editor-2:8.2.2875-1.fc34.noarch conflicts with system-default-editor provided by nano-default-editor-5.6.1-1.fc34.noarch
  - package nano-default-editor-5.6.1-1.fc34.noarch conflicts with system-default-editor provided by vim-default-editor-2:8.2.2875-1.fc34.noarch
  - package nano-default-editor-5.6.1-1.fc34.noarch conflicts with system-default-editor provided by vim-default-editor-2:8.2.2637-1.fc34.noarch
  - package vim-default-editor-2:8.2.2637-1.fc34.noarch conflicts with system-default-editor provided by nano-default-editor-5.6.1-1.fc34.noarch
  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
```

And digging through the groups, I find:

```
$ sudo dnf group install Standard
Last metadata expiration check: 0:44:51 ago on Mon 24 May 2021 06:16:15 CEST.
Error: 
 Problem: problem with installed package vim-default-editor-2:8.2.2875-1.fc34.noarch
  - package vim-default-editor-2:8.2.2875-1.fc34.noarch conflicts with system-default-editor provided by nano-default-editor-5.6.1-1.fc34.noarch
  - package nano-default-editor-5.6.1-1.fc34.noarch conflicts with system-default-editor provided by vim-default-editor-2:8.2.2875-1.fc34.noarch
  - package nano-default-editor-5.6.1-1.fc34.noarch conflicts with system-default-editor provided by vim-default-editor-2:8.2.2637-1.fc34.noarch
  - package vim-default-editor-2:8.2.2637-1.fc34.noarch conflicts with system-default-editor provided by nano-default-editor-5.6.1-1.fc34.noarch
  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
```

And `sudo dnf group upgrade Standard` gives me the same error, so it seems to me that the actual issue is that the "Standard" group should depend on `system-default-editor` as alternative to `nano-default-editor` (I don't know if it's possible for groups, I know this from Debian where your package depends on "virtual-package | actual-package" to handle alternatives)

Anyway, for my part, I'm removing the "Standard" package.

Thanks!  `dnf group install Standard` indeed triggers the conflict above when vim-default-editor is installed.

Chris Murphy and Neal Gompa, could you please clarify how this was supposed to work?

This is working as expected, since "nano-default-editor" is requested in the comps groups explicitly. This is how system upgrades works, since it "upgrades" comps groups and resolves them to satisfy the transaction.

If you want to opt out of that, then you can "remove" the "Standard" group, or set an exclusion for "nano-default-editor".

It definitely does not work as I expected.  If someone manually installed vim-default-editor, they want to use vim as the default editor, independently of the distribution default.  If it prevents the system from being updated, the solution is just broken.

(In reply to Kamil Dudka from comment #7)
> It definitely does not work as I expected.  If someone manually installed
> vim-default-editor, they want to use vim as the default editor,
> independently of the distribution default.  If it prevents the system from
> being updated, the solution is just broken.

The "solution" is correct; however, the handling of comps group entries by DNF may be wrong.

What exactly is wrong in dnf?  Was it already wrong when https://fedoraproject.org/wiki/Changes/UseNanoByDefault was discussed?

A quick (but incomplete) fix to this breakage would be to revert the following patch:

    https://src.fedoraproject.org/rpms/nano/c/df5530fd

As far as I can see, it has never been approved or documented anywhere.

Any better idea?

Asking Fedora users to remove the the "Standard" group in case they are not able to upgrade their system, is not going to work.

Small update, also the group workstation-product-environment brings the issue, without involvement of the Standard group, and I can't decently remove _this_ group...

Without enough knowledge to feel really sure, my impression is that the issue can't be properly solved as long as groups don't support alternative dependencies.
Being able to state that a group depends either on the virtual package system-default-editor _or_ on the package nano-default-editor would solve the issue, because dnf would find out that the virtual package is already provided by vim-default-editor, so that nano-default-editor doesn't need to be installed.

(In reply to Kamil Dudka from comment #9)
> What exactly is wrong in dnf?  Was it already wrong when
> https://fedoraproject.org/wiki/Changes/UseNanoByDefault was discussed?
> 
> A quick (but incomplete) fix to this breakage would be to revert the
> following patch:
> 
>     https://src.fedoraproject.org/rpms/nano/c/df5530fd
> 
> As far as I can see, it has never been approved or documented anywhere.
> 
> Any better idea?
> 
> Asking Fedora users to remove the the "Standard" group in case they are not
> able to upgrade their system, is not going to work.

Having more than one installed at the same time will lead to unexpected/broken behavior, so that prevents it from happening.

(In reply to Eric L. from comment #10)
> Small update, also the group workstation-product-environment brings the
> issue, without involvement of the Standard group, and I can't decently
> remove _this_ group...
> 
> Without enough knowledge to feel really sure, my impression is that the
> issue can't be properly solved as long as groups don't support alternative
> dependencies.
> Being able to state that a group depends either on the virtual package
> system-default-editor _or_ on the package nano-default-editor would solve
> the issue, because dnf would find out that the virtual package is already
> provided by vim-default-editor, so that nano-default-editor doesn't need to
> be installed.

Yes, though it *might* be technically possible to use a rich dep stanza in the group now and DNF *might* do the right thing.

That is, instead of "nano-default-editor", use "(nano-default-editor or system-default-editor)".

Making such an enhancement would be the responsibility of the DNF team, so sending it there...

It looks to me that the current solution based on system-default-editor is already heavily over-engineered yet it does not serve its original purpose.  Instead of waiting for dnf team to solve this mess by adding additional complexity, we might want to rather simplify things.

Here is my proposal:

1. Rename the nano-default-editor subpackage to just default-editor.
2. Drop the vim-default-editor subpackage.
3. Users that want to use a different editor by default will just edit a single file in /etc which will be guarded by %config(noreplace).

User's preferences will be preserved across updates without any conflicts at RPM level.

(In reply to Kamil Dudka from comment #13)
> It looks to me that the current solution based on system-default-editor is
> already heavily over-engineered yet it does not serve its original purpose. 
> Instead of waiting for dnf team to solve this mess by adding additional
> complexity, we might want to rather simplify things.
> 
> Here is my proposal:
> 
> 1. Rename the nano-default-editor subpackage to just default-editor.
> 2. Drop the vim-default-editor subpackage.
> 3. Users that want to use a different editor by default will just edit a
> single file in /etc which will be guarded by %config(noreplace).
> 
> User's preferences will be preserved across updates without any conflicts at
> RPM level.

It was not over-engineered. It was added specifically because people wanted a way to block the nano-default-editor with their own one.

It does not really matter why it was added.  The current situation is that the "solution" is already too complicated yet it does not solve the problem it was intended to solve.

Does anybody have any technical concerns regarding my proposal?

(In reply to Kamil Dudka from comment #15)
> It does not really matter why it was added.  The current situation is that
> the "solution" is already too complicated yet it does not solve the problem
> it was intended to solve.
> 
> Does anybody have any technical concerns regarding my proposal?

Yes. You also don't actually need to change anything as it is now if you want to override the setting in /etc or in $HOME already.

(In reply to Kamil Dudka from comment #15)
> It does not really matter why it was added.  The current situation is that
> the "solution" is already too complicated yet it does not solve the problem
> it was intended to solve.
> 

It *does* matter why it was added. Otherwise it wouldn't have been done in the first place.

And there is an underlying problem here, DNF should not be blocking upgrades on packages that are not mandatory-to-install in comps. I just checked, and we don't have "nano-default-editor" tagged as a mandatory package, and it should be considered equivalent to Recommends and not failing this.

Neal, could you review if I understand the expected behavior correctly?

* If a package (regardless if it's mandatory, default, or optional) in a group is not available, it's skipped
* If a package has an unresolvable dependency (incl. a conflict), dnf errors out

My understanding is that you want us to error out only on packages that are "mandatory" and apply --skip-broken behavior on "default" and "optional".

If that's the case, I don't think it's a good idea.
The package type "mandatory", "default" and "optional" historically refers to Anaconda UI:
* mandatory: always installed as part of the group (if present)
* default: installed as part of the group, but the user can de-select it
* optional: available, user can select it

I don't think we should be adding these values any other meaning.

(In reply to Daniel Mach from comment #19)
> Neal, could you review if I understand the expected behavior correctly?
> 
> * If a package (regardless if it's mandatory, default, or optional) in a
> group is not available, it's skipped
> * If a package has an unresolvable dependency (incl. a conflict), dnf errors
> out
> 
> My understanding is that you want us to error out only on packages that are
> "mandatory" and apply --skip-broken behavior on "default" and "optional".
>
> If that's the case, I don't think it's a good idea.
> The package type "mandatory", "default" and "optional" historically refers
> to Anaconda UI:
> * mandatory: always installed as part of the group (if present)
> * default: installed as part of the group, but the user can de-select it
> * optional: available, user can select it
> 
> I don't think we should be adding these values any other meaning.

The problem is that people are already generally using it this way. Personally, I'd rather comps groups turn into metapackages as people expect, but we are where we are...

Having --skip-broken behavior for default/optional means that overrides actually work as intended.

I as Vim maintainer talked about the issue with Kamil, Nano maintainer, and came up with the following idea:

- vim-default-editor and nano-default-editor will stay as they are
- a new nano subpackage - default-editor - will be introduced, will replace nano-default-editor in dnf group Standard and comps and will have a weak dependency on nano-default-editor

This way the fresh installation will get nano-default-editor by default, and users who have vim-default-editor should not be stopped during upgrade.

Dan, is there a way how we can test the proposed idea with DNF? Unfortunately I don't know how to change groups in DNF :( .

(In reply to Zdenek Dohnal from comment #21)
> and came up with the following idea:
> 

s/and came up/and we came up

Pull request filed https://src.fedoraproject.org/rpms/nano/pull-request/7

*** Bug 1971333 has been marked as a duplicate of this bug. ***

I'm sorry, I should set needinfo to a person assigned to the ticket :) .

Pavli, you couldn't give us an advice how to test the fix with DNF, could you?

Thank you in advance!

Hi Zdenek and Kamil,

I discussed this with Dan and while your solution works, a cleaner solution would be to have the default-editor package as a separate package (instead of as a nano subpackage) that requires a virtual provide (provided by both vim-default-editor and nano-default-editor) and recommends nano-default-editor. We'd have to come up with a good name for the provide, because it obviously cannot be named the same as the default-editor package.

Let me know what do you think about this proposal.

As to how to change comps in Fedora, it's done in fedora-comps repo according to this documentation: https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups#How_to_submit_changes_to_comps

To test it, probably easiest would be to create a simple repository with just the changed comps and the packages that need to change, and add "enablegroups=0" config option for Fedora repos. That way, the comps from the simple repo will be used, but all Fedora packages will be available and you can test installing the Standard group. It's a bit of work, but I don't know of any better way. I can try it out. I can also create a test in dnf test suite, but it won't be with real data.

Hi Pavla,

thank you for the answer!

(In reply to Pavla Kratochvilova from comment #26)
> I discussed this with Dan and while your solution works, a cleaner solution
> would be to have the default-editor package as a separate package (instead
> of as a nano subpackage)

We've considered this as an option, but dismissed it because it looked like an overhead to ship it as a separate component (it would have had to go through fedora review, etc.) instead of being a subpackage of nano (nano was chosen as a default editor, IMO it makes sense to ship 'default-editor' in it if we don't create a separate component).

Is there a downside of the subpackage approach? Only thing I can think of is that 'default-editor' will inherit nano's 'VR', but I don't know of situation in which it makes problems. 

> that requires a virtual provide (provided by both
> vim-default-editor and nano-default-editor) and recommends
> nano-default-editor. We'd have to come up with a good name for the provide,
> because it obviously cannot be named the same as the default-editor package.

vim-default-editor and nano-default-editor provides 'system-default-editor' virtual provide, the package would be 'default-editor'. So we're okay, aren't we?

Ad requiring virtual provide 'system-default-editor' in 'default-editor' - I don't know dnf/rpm internal resolution that much - so I have two questions about that:

1) What would happen if vim-default-editor is installed and some third package provides 'system-default-editor' too, will dnf keep out the third package from the upgrade transaction?

2) what are the pros for its requirement? vim-default-editor will be upgraded anyway and nano-default-editor will be brought in if nothing installed conflicts with it. Maybe for automatic removal of vim-default-editor/nano-default-editor if user removes 'default-editor'?

> 
> Let me know what do you think about this proposal.
> 
> As to how to change comps in Fedora, it's done in fedora-comps repo
> according to this documentation:
> https://fedoraproject.org/wiki/How_to_use_and_edit_comps.
> xml_for_package_groups#How_to_submit_changes_to_comps

Thanks for the link!

> 
> To test it, probably easiest would be to create a simple repository with
> just the changed comps and the packages that need to change, and add
> "enablegroups=0" config option for Fedora repos.

Ok, I hope a repo created by createrepo_c will help there. Tbh I have never tested anything with comps before.

> That way, the comps from
> the simple repo will be used, but all Fedora packages will be available and
> you can test installing the Standard group. It's a bit of work, but I don't
> know of any better way. I can try it out. I can also create a test in dnf
> test suite, but it won't be with real data.

No problem, always good to know new things. I'll try to set it up.

(In reply to Zdenek Dohnal from comment #27)
> Hi Pavla,
> 
> thank you for the answer!
> 
> (In reply to Pavla Kratochvilova from comment #26)
> > I discussed this with Dan and while your solution works, a cleaner solution
> > would be to have the default-editor package as a separate package (instead
> > of as a nano subpackage)
> 
> We've considered this as an option, but dismissed it because it looked like
> an overhead to ship it as a separate component (it would have had to go
> through fedora review, etc.) instead of being a subpackage of nano (nano was
> chosen as a default editor, IMO it makes sense to ship 'default-editor' in
> it if we don't create a separate component).
> 
> Is there a downside of the subpackage approach? Only thing I can think of is
> that 'default-editor' will inherit nano's 'VR', but I don't know of
> situation in which it makes problems. 

I don't know of any downside, it just seems kind of weird if it's a nano subpackage, but I get it.

> > that requires a virtual provide (provided by both
> > vim-default-editor and nano-default-editor) and recommends
> > nano-default-editor. We'd have to come up with a good name for the provide,
> > because it obviously cannot be named the same as the default-editor package.
> 
> vim-default-editor and nano-default-editor provides 'system-default-editor'
> virtual provide, the package would be 'default-editor'. So we're okay,
> aren't we?

Oh, right, I didn't notice. The naming is good there.

> Ad requiring virtual provide 'system-default-editor' in 'default-editor' - I
> don't know dnf/rpm internal resolution that much - so I have two questions
> about that:
> 
> 1) What would happen if vim-default-editor is installed and some third
> package provides 'system-default-editor' too, will dnf keep out the third
> package from the upgrade transaction?

The dependency is already satisfied by vim-default-editor, so nothing else should get installed.

> 2) what are the pros for its requirement? vim-default-editor will be
> upgraded anyway and nano-default-editor will be brought in if nothing
> installed conflicts with it. Maybe for automatic removal of
> vim-default-editor/nano-default-editor if user removes 'default-editor'?

It's actually just the opposite - default-editor gets removed if nano-default-editor is removed. (The other way is true in both cases.)

It would also mean, that if you excluded nano-default-editor, dnf would try to satisfy the dependency with another system-default-editor and you would never end up with default-editor installed, without actually having any default editor package installed.

> > Let me know what do you think about this proposal.
> > 
> > As to how to change comps in Fedora, it's done in fedora-comps repo
> > according to this documentation:
> > https://fedoraproject.org/wiki/How_to_use_and_edit_comps.
> > xml_for_package_groups#How_to_submit_changes_to_comps
> 
> Thanks for the link!
> 
> > 
> > To test it, probably easiest would be to create a simple repository with
> > just the changed comps and the packages that need to change, and add
> > "enablegroups=0" config option for Fedora repos.
> 
> Ok, I hope a repo created by createrepo_c will help there. Tbh I have never
> tested anything with comps before.

Yes, and the option --groupfile to specify the comps.

> > That way, the comps from
> > the simple repo will be used, but all Fedora packages will be available and
> > you can test installing the Standard group. It's a bit of work, but I don't
> > know of any better way. I can try it out. I can also create a test in dnf
> > test suite, but it won't be with real data.
> 
> No problem, always good to know new things. I'll try to set it up.

Ok, let me know if you need any help!

(In reply to Pavla Kratochvilova from comment #28)
> I don't know of any downside, it just seems kind of weird if it's a nano subpackage, but I get it.

This kind of weirdness is acceptable for me.  Someone might find it weird to use nano as the default editor on a Linux system but that is another story :-)  If we have a volunteer to drive the Fedora new package process and to become the maintainer of such a new package, I will definitely support the effort.  If not, I would prefer to move forward the pull request mentioned in comment #23.

I managed to verify the current PR for nano works during installing 'Standard' group from created repository.

Without fixed comps and default-editor package I get:

$ dnf group install Standard
Last metadata expiration check: 2:07:55 ago on Tue 22 Jun 2021 11:43:34 PM EDT.
Error: 
 Problem: problem with installed package vim-default-editor-2:8.2.2875-1.fc33.noarch
  - package vim-default-editor-2:8.2.2875-1.fc33.noarch conflicts with system-default-editor provided by nano-default-editor-5.3-4.fc33.noarch
  - package nano-default-editor-5.3-4.fc33.noarch conflicts with system-default-editor provided by vim-default-editor-2:8.2.2875-1.fc33.noarch
  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)

The other groups which have nano-default-editor as default dependency are affected too - namely:

security-lab
workstation-product

=============================================================================================================================

Test setup:

1) install createrepo_c and vim-default-editor (nano-default-editor isn't installed)

2) upload new built nano rpms (with default-editor rpm) into some dir - f.e. /root/nano

3) download comps file from its pagure

# wget -O comps.xml https://pagure.io/fedora-comps/raw/main/f/comps-f33.xml.in

4) remove nano+nano-default-editor from standard, security-lab and workstation-product groups and put default-editor into them

5) create a local repo

# createrepo --database nano/ --groupfile ~/comps.xml

6) create a repo file /etc/yum.repos.d/local-nano.repo with contents:

[local-nano.repo]
name=local-nano
baseurl=file:/root/nano
enabled=1
gpgcheck=0

7) disable groups for any other Fedora repos in your system by adding 'enablegroups=0' to their repo files in /etc/yum.repos.d

===============================================================================================================================

Now if I run 'group install', the fixed local comps are loaded and no transaction error is hit if vim-default-editor is installed. If vim-default-editor isn't installed, nano-default-editor is correctly brought in.


So IMO the fix is verified and it can be merged into nano. After the fix gets into stable F33 and F34, we can create a PR for fedora-comps.

Fedora commit: https://src.fedoraproject.org/rpms/nano/c/e53ee57b

FEDORA-2021-585020e53e has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-585020e53e

FEDORA-2021-02d1eae15d has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-02d1eae15d

The fix for comps lives on default_editor branch of my fedora-comps fork - https://pagure.io/fork/zdohnal/fedora-comps/c/813bc53bef2eaaea78c528f30b08bc083795e045?branch=default_editor

Once nano updates reaches the stable, I'll open PR to fedora-comps.

FEDORA-2021-02d1eae15d has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-585020e53e has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-585020e53e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-585020e53e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-585020e53e has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Updates are in stable now, created PR to fedora-comps - https://pagure.io/fedora-comps/pull-request/663 .

The PR is merged, checking if the comps fix has got into production already...

It seems the new comps still haven't reached the public repos:

(current F33 from 1mt):

# sudo dnf group install Standard
Last metadata expiration check: 0:00:35 ago on Thu 15 Jul 2021 08:39:27 AM EDT.
Error: 
 Problem: problem with installed package vim-default-editor-2:8.2.3046-1.fc33.noarch
  - package vim-default-editor-2:8.2.3046-1.fc33.noarch conflicts with system-default-editor provided by nano-default-editor-5.3-4.fc33.noarch
  - package nano-default-editor-5.3-4.fc33.noarch conflicts with system-default-editor provided by vim-default-editor-2:8.2.3046-1.fc33.noarch
  - conflicting requests
  - package vim-default-editor-2:8.2.3046-1.fc33.noarch conflicts with system-default-editor provided by nano-default-editor-5.8-2.fc33.noarch
  - package nano-default-editor-5.8-2.fc33.noarch conflicts with system-default-editor provided by vim-default-editor-2:8.2.3046-1.fc33.noarch
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)

Ok, I was mistaken - the original comps for 'fedora' repo cannot be updated after release, and these comps contain the issue. The possible workaround is to disable 'fedora' repo from the transaction:

$ sudo dnf group install --disablerepo=fedora Standard
Last metadata expiration check: 0:59:34 ago on Thu 05 Aug 2021 03:07:25 PM CEST.
No match for group package "irqbalance"
Dependencies resolved.
==============================================================================================================================
 Package                          Architecture             Version                            Repository                 Size
==============================================================================================================================
Installing group/module packages:
 default-editor                   noarch                   5.8-3.fc33                         updates                   9.1 k
 opensc                           x86_64                   0.21.0-1.fc33                      updates                   1.2 M
 smartmontools                    x86_64                   1:7.2-2.fc33                       updates                   557 k
Installing dependencies:
 pcsc-lite                        x86_64                   1.9.1-1.fc33                       updates                    91 k
 pcsc-lite-ccid                   x86_64                   1.4.34-1.fc33                      updates                   300 k
Installing Groups:
 Standard                                                                                                                    

Transaction Summary
==============================================================================================================================
Install  5 Packages

Total download size: 2.2 M
Installed size: 7.3 M
Is this ok [y/N]:

'fedora-updates' repo has already fixed comps, so disabling 'fedora' repo is a workaround.

So upgrades F33->F34 and the affected group installations in F33 and F34 will be still affected because of issue in the comps, the clear upgrade path and clean group installation will in F35 and during upgrade F34->F35.

Nice.  Thank you for taking care of it, Zdenek!

Looks like this commit
https://pagure.io/fedora-comps/c/3496ed634cf452da38cc2796c6710e1de6cbc23a?branch=main

Broke nano by default on Fedora-Server-dvd-x86_64-35-1.2.iso which is made in pungi
https://pagure.io/pungi-fedora/blob/main/f/variants-fedora.xml#_37-66

We should probably discuss in this Server edition thread how to fix it, or maybe it needs to be escalated to FESCo to figure out what to do now - even though it's too late for Fedora 35 since it's out the door now. :\
https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/message/ZI56UQQGRIKJ6ZMCGM2ULMSNLQMM4F5P/

This could be a problem in pungi that it does not handle weak dependencies properly.  But users can still install nano-default-editor after the installation and it works just fine, doesn't it?

Users can 'dnf install nano-default-editor --allow-erasing'

Let's keep this bug closed then, and Server WG and Releng can work out if a bug needs to be opened against pungi.