Additional information (corrrection):

When going into the MCC to install virt-manager, the listed dependencies include the two selected packages above: lib64capstone4 and netcat-traditional, not the netcat-openbsd or python3-capstone packages.

When you use MCC, some deps get automatically chosen for you. As commandline is in most cases more verbose, it asks you which available package you want to chose.

virt-manager installs just fine  no matter which dependency you chose. It is only an information that if you chose netcat-traditional that you can't install additionally netcat-openbsd as they can't be installed at the same time.

So this message can be ignored by you.

(In reply to Edward from comment #0)

> Wanted to install virt-manager to install and try out Mageia Cauldron in a
> vm, ...

BTW for a virtual machine most of our guys use Virtualbox. We also have a good wiki page for it: https://wiki.mageia.org/en/VirtualBox

The only experience I have with virtual machines, is with past distros. I used Gnome Boxes on Fedora and virt-manager on Debian (both using LXQt). I found Gnome Boxes the easier of the two to use, but with virt-manager, the OS database at the time was outdated and had some trouble getting it to recognize and install certain images, it was pretty much trial-and-error. :)

Thanks for the wiki link.

I confirm Edwards initial complaint. Even if happens to be cosmetic - "A requested package cannot be installed: netcat-openbsd" - when that package has NOT been chosen for installation, it is disconcerting. Edward replied not to install; asking for the installation to proceed would have I think worked, as sturmvogel found.

My own tests, noting just the 'netcat' choice:

a) the 'traditional' choice:
In order to satisfy the 'netcat' dependency, one of the following packages is needed:
 1- netcat-traditional-1.10-42.mga8.x86_64: Reads and writes data across network connections using TCP or UDP (to install)
 2- netcat-openbsd-1.89-12.mga8.x86_64: Reads and writes data across network connections using TCP or UDP (to install)
What is your choice? (1-2) 1
A requested package cannot be installed:
netcat-openbsd-1.89-12.mga8.x86_64 (due to conflicts with netcat-traditional-1.10-42.mga8.x86_64)
Continue installation anyway? (Y/n) y
To satisfy dependencies, the following packages are going to be installed:
 looks as if it would have worked, with 'netcat-traditional'.

b) The 'openbsd' choice:
In order to satisfy the 'netcat' dependency, one of the following packages is needed:
 1- netcat-traditional-1.10-42.mga8.x86_64: Reads and writes data across network connections using TCP or UDP (to install)
 2- netcat-openbsd-1.89-12.mga8.x86_64: Reads and writes data across network connections using TCP or UDP (to install)
What is your choice? (1-2) 2
 [*no* conflict message]
To satisfy dependencies, the following packages are going to be installed:
 with 'netcat-openbsd'.

So the conflict message (for netcat-openbsd-1.89-12.mga8.x86_64) only happens if
 1- netcat-traditional-1.10-42.mga8.x86_64
is chosen, but not the other way round.

Assigning this to ThierryV who does 'virt-manager', and happens also to be the last committer for 'netcat-traditional' - unsure where the problem lies.

Source RPM: virt-manager-3.2.0-2.mga8.noarch.rpm => virt-manager-3.2.0-2.mga8.noarch.rpm, netcat-traditional-1.10-42.mga8.src.rpm
Whiteboard: (none) => CAULDRON TOO?
Assignee: bugsquad => thierry.vignaud

Unfortunately, I found virt-manager to run extremely slow, it seemed like it took forever just to install an image (from hard drive), so I removed it.

What I thought might happen when I removed virt-manager, happened.

When I used the MCC to install virt-manager, this is what else it wanted to install:

To satisfy dependencies, the following package(s) also need to be installed:

- augeas-lenses-1.12.0-3.mga8.x86_64
- dconf-0.38.0-1.mga8.x86_64
- dnsmasq-2.85-4.mga8.x86_64
- edk2-ovmf-20201127stable-1.mga8.noarch
- edk2-ovmf-ia32-20201127stable-1.mga8.noarch
- gtk-vnc-i18n-1.0.0-3.mga8.noarch
- gtksourceview-4.8.0-1.mga8.x86_64
- ipxe-roms-qemu-20200823-1.mga8.noarch
- jq-1.6-2.mga8.x86_64
- lib64augeas0-1.12.0-3.mga8.x86_64
- lib64brlapi0.8-6.1-5.mga8.x86_64
- lib64cacard0-2.7.0-2.mga8.x86_64
- lib64capstone4-4.0.2-1.mga8.x86_64
- lib64daxctl1-68-2.mga8.x86_64
- lib64fa1-1.12.0-3.mga8.x86_64
- lib64fdt1-1.5.1-3.mga8.x86_64
- lib64gst-gir1.0-1.18.5-1.mga8.x86_64
- lib64gtk-vnc2.0_0-1.0.0-3.mga8.x86_64
- lib64gtksourceview-gir4-4.8.0-1.mga8.x86_64
- lib64gtksourceview4_0-4.8.0-1.mga8.x86_64
- lib64gtkvnc-gir2.0-1.0.0-3.mga8.x86_64
- lib64gvnc-gir1.0-1.0.0-3.mga8.x86_64
- lib64gvnc1.0_0-1.0.0-3.mga8.x86_64
- lib64ibverbs1-1.2.1-4.mga8.x86_64
- lib64iscsi9-1.19.0-0.git6ea30ae.mga8.x86_64
- lib64jq1-1.6-2.mga8.x86_64
- lib64mpathcmd0-0.8.5-2.mga8.x86_64
- lib64mpathpersist0-0.8.5-2.mga8.x86_64
- lib64multipath0-0.8.5-2.mga8.x86_64
- lib64netcf1-0.2.8-7.mga8.x86_64
- lib64nl-route3_200-3.5.0-2.mga8.x86_64
- lib64osinfo-gir1.0-1.8.0-2.mga8.x86_64
- lib64osinfo1.0_0-1.8.0-2.mga8.x86_64
- lib64phodav2.0_0-2.5-1.mga8.x86_64
- lib64rdmacm1-1.1.0-4.mga8.x86_64
- lib64slirp0-4.4.0-1.1.mga8.x86_64
- lib64spice-client-glib-gir2.0-0.38-2.mga8.x86_64
- lib64spice-client-glib2.0_8-0.38-2.mga8.x86_64
- lib64spice-client-gtk-gir3.0-0.38-2.mga8.x86_64
- lib64spice-client-gtk3.0_5-0.38-2.mga8.x86_64
- lib64spice-server1-0.14.3-3.1.mga8.x86_64
- lib64uring1-0.7-2.mga8.x86_64
- lib64usbredirhost1-0.8.0-3.1.mga8.x86_64
- lib64usbredirparser1-0.8.0-3.1.mga8.x86_64
- lib64virglrenderer1-0.8.2-1.20200212git7d204f39.mga8.x86_64
- lib64virt-glib-gir1.0-3.0.0-2.mga8.x86_64
- lib64virt-glib1.0_0-3.0.0-2.mga8.x86_64
- lib64virt0-7.0.0-2.2.mga8.x86_64
- lib64xen3.0-4.14.1-1.mga8.x86_64
- lib64xml2-gir2.0-1.66.1-1.mga8.x86_64
- lib64yajl2-2.1.0-3.mga8.x86_64
- libosinfo-1.8.0-2.mga8.x86_64
- libvirt-utils-7.0.0-2.2.mga8.x86_64
- libxml2-python3-2.9.10-7.4.mga8.x86_64
- mdevctl-0.78-1.mga8.noarch
- netcat-traditional-1.10-42.mga8.x86_64
- netcf-0.2.8-7.mga8.x86_64
- osinfo-db-20201218-1.mga8.noarch
- osinfo-db-tools-1.8.0-1.mga8.x86_64
- phodav-i18n-2.5-1.mga8.noarch
- python3-argcomplete-1.12.0-1.mga8.noarch
- python3-libvirt-6.10.0-1.mga8.x86_64
- qemu-audio-alsa-5.2.0-4.mga8.x86_64
- qemu-audio-oss-5.2.0-4.mga8.x86_64
- qemu-audio-pa-5.2.0-4.mga8.x86_64
- qemu-audio-sdl-5.2.0-4.mga8.x86_64
- qemu-audio-spice-5.2.0-4.mga8.x86_64
- qemu-block-curl-5.2.0-4.mga8.x86_64
- qemu-block-dmg-5.2.0-4.mga8.x86_64
- qemu-block-iscsi-5.2.0-4.mga8.x86_64
- qemu-block-nfs-5.2.0-4.mga8.x86_64
- qemu-block-ssh-5.2.0-4.mga8.x86_64
- qemu-char-baum-5.2.0-4.mga8.x86_64
- qemu-char-spice-5.2.0-4.mga8.x86_64
- qemu-common-5.2.0-4.mga8.x86_64
- qemu-device-display-qxl-5.2.0-4.mga8.x86_64
- qemu-device-display-virtio-gpu-5.2.0-4.mga8.x86_64
- qemu-device-display-virtio-gpu-pci-5.2.0-4.mga8.x86_64
- qemu-device-display-virtio-vga-5.2.0-4.mga8.x86_64
- qemu-device-usb-redirect-5.2.0-4.mga8.x86_64
- qemu-device-usb-smartcard-5.2.0-4.mga8.x86_64
- qemu-img-5.2.0-4.mga8.x86_64
- qemu-kvm-5.2.0-4.mga8.x86_64
- qemu-system-x86-5.2.0-4.mga8.x86_64
- qemu-system-x86-core-5.2.0-4.mga8.x86_64
- qemu-ui-curses-5.2.0-4.mga8.x86_64
- qemu-ui-egl-headless-5.2.0-4.mga8.x86_64
- qemu-ui-gtk-5.2.0-4.mga8.x86_64
- qemu-ui-opengl-5.2.0-4.mga8.x86_64
- qemu-ui-sdl-5.2.0-4.mga8.x86_64
- qemu-ui-spice-app-5.2.0-4.mga8.x86_64
- qemu-ui-spice-core-5.2.0-4.mga8.x86_64
- seabios-bin-1.14.0-1.mga8.noarch
- seavgabios-bin-1.14.0-1.mga8.noarch
- sgabios-bin-0.20180715git-1.mga8.noarch
- spice-gtk-0.38-2.mga8.x86_64
- virt-manager-common-3.2.0-2.mga8.noarch
- xen-licenses-4.14.1-1.mga8.x86_64

140MB of additional disk space will be used.

When I used urpme to remove virt-manager:

~]$ sudo urpme --auto-orphans
To satisfy dependencies, the following 8 packages will be removed (994KB):
  
(orphan packages)
  gtk-vnc-i18n-1.0.0-3.mga8.noarch
  lib64gtk-vnc2.0_0-1.0.0-3.mga8.x86_64
  lib64gtkvnc-gir2.0-1.0.0-3.mga8.x86_64
  lib64gvnc-gir1.0-1.0.0-3.mga8.x86_64
  lib64gvnc1.0_0-1.0.0-3.mga8.x86_64
  lib64virt-glib-gir1.0-3.0.0-2.mga8.x86_64
  lib64virt-glib1.0_0-3.0.0-2.mga8.x86_64
  spice-gtk-0.38-2.mga8.x86_64
Remove 8 packages? (y/N) y

Could there be a reason why the remaining 90 packages also weren't removed using the urpme command?

That's normal with urpmi or other package managers. The dependencies require
virt-manager. Without it, they can not work.

The orphan packages are required by virt-manager, but may also be used by other
programs including programs installed using source code instead of packages.

It's up to the administrator to decide whether or not they need the orphan
packages for other purposes.

Also see https://wiki.mageia.org/en/Removing_packages#Warning
Using auto orphans can remove your desktop environment if you're not careful.

CC: (none) => davidwhodgins

I removed those eight via auto-orphans and went into the MCC to manually remove the remaining 90 packages. I will not use auto-orphans if it will remove things that I think I might need, like a desktop environment.  :)

To be honest, If virt-manager *required* those 98 packages, then shouldn't auto-orphans have removed all 98 along with virt-manager, instead of the eight flagged by it? 

I obviously have nothing else installed that required the remaining 90. None of the listed packages were installed prior.

I regularly use auto-orphans, but I never answer yes to actually removing
the packages without checking the list carefully. If necessary, I use urpmi
to install some of the would be orphans again (without having removed them).
Manually installing a package removes the package from
/var/lib/rpm/installed-through-deps.list, which is the list of packages
installed by other packages requiring them, making them candidates for
orphans if the package that required them was removed.

As to the auto-orphans not removing the other packages, it's because one
of the packages required when installing virt-manager either suggests or
recommends them, rather then requiring them. A subtle difference, but
recommended or suggested packages are handled differently than required packages.

"To satisfy dependencies, the following package(s) also need to be installed:"

This is where it gets confusing. With rpmdrake using the above statement, it implies that the listed packages are *required*, not recommended. 

Is it possible that an entry in ...installed-through-deps.list may have been incorrect when virt-manager was installed, by auto-orphans not detecting the remaining 90 packages?

If additional packages are *recommended* upon installing something specific, then could an option be added to rpmdrake/urpmi to install them and not have them force-installed?

From "man urpmi" ...
       --no-recommends
           With this option, urpmi will not install "recommended" packages.  By default, urpmi will install (newly) recommended packages.

Without the --no-recommends command line option or setting in /etc/urpmi.cfg,
urpmi will install recommended packages in much the same way as required
packages, with the exception of adding them to the installed as dependencies
list.

As to the conflict, in the description of this bug, that's intentional.

Either install virt-manager and the version of netcat it needs, or the
the other version of netcat, allowing the packages that require that version.
Not both.

Also, never try to run any sort of a virtual machine inside of a virtual
machine. In the case of starting virtualbox while the kernel is running
under the xen-hypervisor, it will force a hard reset of the host system.
That is something I learned the hard way. :-)

Closing the bug as invalid. Feel free to add more comments or to reopen if
I've misunderstood the situation.

Status: NEW => RESOLVED
Resolution: (none) => INVALID

Basically, I couldn't do anything with it, as it simply ran too slow. 

There was also a message at startup of virt-manager, that KVM was not installed and the virtual machine might not run correctly. 

In the list above, qemu-kvm is listed and was installed, in which the description shows it installs qemu-system-x86. There is also a package qemu-kvm-core (not listed above) which installs qemu-system-x86-core, but it shows that package was installed anyway, so I don't know what else would have triggered the KVM message, or whether if something else was missing, is that why it ran so slow.

I discovered what was causing the slowdown and corrected that (BIOS setting), however was unable to get the network working at all, despite trying all settings, so it's being removed a second time. Not Mageia's fault.