Bug 1955884 - DNF is blocking upgrades on weak-install items in comps groups (e.g. nano-default-editor)
Summary: DNF is blocking upgrades on weak-install items in comps groups (e.g. nano-def...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: nano
Version: 34
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1971333 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-01 09:30 UTC by Eric L.
Modified: 2021-11-12 02:52 UTC (History)
16 users (show)

Fixed In Version: nano-5.8-2.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-05 14:11:20 UTC
Type: Bug


Attachments (Terms of Use)

Description Eric L. 2021-05-01 09:30:57 UTC
Description of problem:
`dnf system-upgrade download --releasever 34` fails with following error:

```
 Problem 2: problem with installed package vim-default-editor-2:8.2.2811-1.fc33.noarch
  - package vim-default-editor-2:8.2.2811-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.2811-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
  - vim-default-editor-2:8.2.2811-1.fc33.noarch does not belong to a distupgrade repository
  - conflicting requests
```

Version-Release number of selected component (if applicable):

```
$ rpm -qa | grep default-editor
vim-default-editor-8.2.2811-1.fc33.noarch
```
(nano isn't installed)

How reproducible:

Always so far...

Steps to Reproduce:

1. Be on F33 (Cinnamon)
2. call `dnf upgrade --refresh`
3. call `dnf system-upgrade download --releasever 34`

Actual results:
Upgrade fails

Expected results:
Upgrade starts

Additional info:
I suspect that it is a follow-up of https://bugzilla.redhat.com/show_bug.cgi?id=1896707 with something still trying to enforce nano as default editor even though I've installed vim-default-editor.
I had reported the duplicate bug https://bugzilla.redhat.com/show_bug.cgi?id=1900543 at that time.

Comment 1 Kamil Dudka 2021-05-03 10:50:15 UTC
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

Comment 2 Kamil Dudka 2021-05-18 07:49:38 UTC
Do we have any self-contained reproducer for this?

Comment 3 Eric L. 2021-05-24 04:42:51 UTC
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.

Comment 4 Eric L. 2021-05-24 05:10:16 UTC
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.

Comment 5 Kamil Dudka 2021-05-24 14:29:01 UTC
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?

Comment 6 Neal Gompa 2021-05-24 21:39:37 UTC
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".

Comment 7 Kamil Dudka 2021-05-25 06:45:39 UTC
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.

Comment 8 Neal Gompa 2021-05-25 11:18:32 UTC
(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.

Comment 9 Kamil Dudka 2021-05-25 13:41:34 UTC
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.

Comment 10 Eric L. 2021-06-11 13:34:32 UTC
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.

Comment 11 Neal Gompa 2021-06-11 13:52:30 UTC
(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)".

Comment 12 Neal Gompa 2021-06-11 13:53:54 UTC
Making such an enhancement would be the responsibility of the DNF team, so sending it there...

Comment 13 Kamil Dudka 2021-06-11 15:43:06 UTC
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.

Comment 14 Neal Gompa 2021-06-12 16:35:53 UTC
(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.

Comment 15 Kamil Dudka 2021-06-14 07:35:09 UTC
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?

Comment 16 Neal Gompa 2021-06-14 11:12:12 UTC
(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.

Comment 17 Neal Gompa 2021-06-14 11:14:15 UTC
(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.

Comment 18 Neal Gompa 2021-06-14 11:20:08 UTC
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.

Comment 19 Daniel Mach 2021-06-14 11:37:03 UTC
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.

Comment 20 Neal Gompa 2021-06-14 11:45:25 UTC
(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.

Comment 21 Zdenek Dohnal 2021-06-16 09:49:18 UTC
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 :( .

Comment 22 Zdenek Dohnal 2021-06-16 09:52:19 UTC
(In reply to Zdenek Dohnal from comment #21)
> and came up with the following idea:
> 

s/and came up/and we came up

Comment 23 Zdenek Dohnal 2021-06-16 10:44:26 UTC
Pull request filed https://src.fedoraproject.org/rpms/nano/pull-request/7

Comment 24 Zdenek Dohnal 2021-06-16 10:55:20 UTC
*** Bug 1971333 has been marked as a duplicate of this bug. ***

Comment 25 Zdenek Dohnal 2021-06-17 04:42:54 UTC
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!

Comment 26 Pavla Kratochvilova 2021-06-17 09:48:49 UTC
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.

Comment 27 Zdenek Dohnal 2021-06-17 11:57:54 UTC
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.

Comment 28 Pavla Kratochvilova 2021-06-17 12:53:14 UTC
(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!

Comment 29 Kamil Dudka 2021-06-17 13:07:10 UTC
(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.

Comment 30 Zdenek Dohnal 2021-06-23 07:12:58 UTC
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.

Comment 31 Kamil Dudka 2021-06-23 07:28:03 UTC
Fedora commit: https://src.fedoraproject.org/rpms/nano/c/e53ee57b

Comment 32 Fedora Update System 2021-06-23 07:36:08 UTC
FEDORA-2021-585020e53e has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-585020e53e

Comment 33 Kamil Dudka 2021-06-23 07:47:24 UTC
FEDORA-2021-02d1eae15d has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-02d1eae15d

Comment 34 Zdenek Dohnal 2021-06-23 09:44:44 UTC
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.

Comment 35 Fedora Update System 2021-06-24 16:52:46 UTC
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.

Comment 36 Fedora Update System 2021-06-24 17:38:23 UTC
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.

Comment 37 Fedora Update System 2021-06-29 01:19:18 UTC
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.

Comment 38 Zdenek Dohnal 2021-06-29 05:42:38 UTC
Updates are in stable now, created PR to fedora-comps - https://pagure.io/fedora-comps/pull-request/663 .

Comment 39 Zdenek Dohnal 2021-07-15 12:38:29 UTC
The PR is merged, checking if the comps fix has got into production already...

Comment 40 Zdenek Dohnal 2021-07-15 12:44:09 UTC
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)

Comment 41 Zdenek Dohnal 2021-08-05 14:11:20 UTC
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.

Comment 42 Kamil Dudka 2021-08-05 14:17:54 UTC
Nice.  Thank you for taking care of it, Zdenek!

Comment 43 Chris Murphy 2021-11-10 02:12:35 UTC
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/

Comment 44 Kamil Dudka 2021-11-10 21:27:23 UTC
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?

Comment 45 Chris Murphy 2021-11-12 02:52:51 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.