Description of problem: On a server without desktop-y stuff installed, osinfo-detect does not work: # osinfo-detect https://ftp.fau.de/fedora/linux/releases/29/Server/x86_64/os/images/boot.iso Error parsing media: Failed to open fileOperation not supported It starts working once installing gvfs. However, this drags in a lot of stuff which doesn't really belong on a server, and isn't required for gvfs to work: Installing: gvfs x86_64 1.38.1-2.fc29 updates 315 k Installing dependencies: adwaita-cursor-theme noarch 3.30.1-1.fc29 updates 644 k adwaita-icon-theme noarch 3.30.1-1.fc29 updates 11 M colord-libs x86_64 1.4.4-1.fc29 updates 208 k gcr x86_64 3.28.1-1.fc29 updates 667 k gdk-pixbuf2-modules x86_64 2.38.1-1.fc29 updates 86 k gtk-update-icon-cache x86_64 3.24.1-3.fc29 updates 31 k gtk3 x86_64 3.24.1-3.fc29 updates 4.5 M gvfs-client x86_64 1.38.1-2.fc29 updates 744 k jbigkit-libs x86_64 2.1-15.fc29 updates 49 k libtiff x86_64 4.0.10-4.fc29 updates 166 k pango x86_64 1.42.4-2.fc29 updates 258 k at-spi2-atk x86_64 2.30.0-1.fc29 fedora 77 k at-spi2-core x86_64 2.30.0-2.fc29 fedora 155 k atk x86_64 2.30.0-1.fc29 fedora 257 k avahi-glib x86_64 0.7-16.fc29 fedora 13 k desktop-file-utils x86_64 0.23-9.fc29 fedora 70 k fribidi x86_64 1.0.5-1.fc29 fedora 82 k graphite2 x86_64 1.3.10-6.fc29 fedora 108 k harfbuzz x86_64 1.8.7-1.fc29 fedora 333 k hicolor-icon-theme noarch 0.17-3.fc29 fedora 44 k jasper-libs x86_64 2.0.14-7.fc29 fedora 160 k lcms2 x86_64 2.9-4.fc29 fedora 150 k libXcomposite x86_64 0.4.4-15.fc29 fedora 22 k libXcursor x86_64 1.1.15-4.fc29 fedora 29 k libXdamage x86_64 1.1.4-15.fc29 fedora 21 k libXfixes x86_64 5.0.3-8.fc29 fedora 18 k libXft x86_64 2.3.2-11.fc29 fedora 59 k libXi x86_64 1.7.9-8.fc29 fedora 38 k libXinerama x86_64 1.1.4-2.fc29 fedora 14 k libXrandr x86_64 1.5.1-8.fc29 fedora 26 k libXtst x86_64 1.2.3-8.fc29 fedora 20 k libbluray x86_64 1.0.2-4.fc29 fedora 156 k libcdio x86_64 2.0.0-3.fc29 fedora 248 k libcdio-paranoia x86_64 10.2+0.94+2-4.fc29 fedora 89 k libdatrie x86_64 0.2.9-8.fc29 fedora 31 k libepoxy x86_64 1.5.3-1.fc29 fedora 197 k libgusb x86_64 0.3.0-2.fc29 fedora 45 k libthai x86_64 0.1.28-1.fc29 fedora 199 k libwayland-client x86_64 1.16.0-1.fc29 fedora 31 k libwayland-cursor x86_64 1.16.0-1.fc29 fedora 19 k libwayland-egl x86_64 1.16.0-1.fc29 fedora 13 k rest x86_64 0.8.1-4.fc29 fedora 65 k Installing weak dependencies: dconf x86_64 0.30.1-1.fc29 updates 93 k Transaction Summary =================================================================================================================================================================== Install 44 Packages Total download size: 22 M Installed size: 60 M I filed bug 1698842 about the excessive dependency, they are mostly due to dragging in gtk3. On the libosinfo side, it either needs to declare a dependency on gvfs, or stop using the http gio file system and just download files via URLs. (Note that glib-networking is fine, it doesn't need gvfs and doesn't have unreasonable dependencies). Version-Release number of selected component (if applicable): libosinfo-1.2.0-5.fc29.x86_64
FWIW, it appears that both --type=media and --type=tree just load ONE url with a well-known name (.treeinfo or the .iso itself). Neither of this needs the full gvfs API, this could just be done at least as easily with a direct URL retrieval? gvfs makes sense if you need to read and iterate through remote directory listings and such, but it appears that isn't being done? But anyway, with fidencio's work with reducing gvfs' dependencies (which is useful no matter what), this is not a big issue.
(In reply to Martin Pitt from comment #1) > FWIW, it appears that both --type=media and --type=tree just load ONE url > with a well-known name (.treeinfo or the .iso itself). Neither of this needs > the full gvfs API, this could just be done at least as easily with a direct > URL retrieval? gvfs makes sense if you need to read and iterate through > remote directory listings and such, but it appears that isn't being done? Directory listing is just one feature in gvfs and not the most important. The key benefit of gvfs is that it allows applications to be completely agnostic to the URI format, and have a standard, well tested impl to use. Before gvfs every application would have to implement its own URI handling & inevitably every app supported a different subset of URIs, and there were different bugs spread across every apps usage of curl & equivalent libraries. Going back to using libraries like curl directory would be a big step backwards over using gvfs.
libosinfo-1.4.0-3.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-da01a7644b
libosinfo-1.2.0-7.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-0337a2a848
libosinfo-1.4.0-3.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-da01a7644b
libosinfo-1.2.0-7.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0337a2a848
So long story short (for me) if i want virt-manager then i will have to accept gvfs and gvfs-client.
libosinfo-1.4.0-3.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
libosinfo-1.2.0-7.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
I reached this bugreport by reading libosinfo changelog. On EL systems like RHEL / CentOS 8, if you try to install virt-install package on a headless machine, libosinfo it will trigger the installation of a lot of graphic libraries: # dnf remove --assumeno virt-install Modular dependency problems: Problema 1: conflicting requests - nothing provides module(perl:5.26) needed by module perl-DBD-SQLite:1.58:8010020191114033549:073fa5fe-0.x86_64 Problema 2: conflicting requests - nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8010020191113222731:16b3ab4d-0.x86_64 Dipendenze risolte. ========================================================================================================================================================================== Package Architecture Version Repository Size ========================================================================================================================================================================== Rimozione in corso: virt-install noarch 2.2.1-2.el8 @AppStream 96 k Rimozione dipendenze inutilizzate: adwaita-cursor-theme noarch 3.28.0-2.el8 @AppStream 11 M adwaita-icon-theme noarch 3.28.0-2.el8 @AppStream 13 M at-spi2-atk x86_64 2.26.2-1.el8 @AppStream 247 k at-spi2-core x86_64 2.28.0-1.el8 @AppStream 502 k atk x86_64 2.28.1-1.el8 @AppStream 1.2 M avahi-glib x86_64 0.7-19.el8 @BaseOS 16 k colord-libs x86_64 1.4.2-1.el8 @AppStream 824 k dconf x86_64 0.28.0-3.el8 @AppStream 317 k gcr x86_64 3.28.0-1.el8 @AppStream 2.6 M gdk-pixbuf2-modules x86_64 2.36.12-5.el8 @AppStream 308 k genisoimage x86_64 1.1.11-39.el8 @AppStream 1.1 M gtk-update-icon-cache x86_64 3.22.30-4.el8 @AppStream 62 k gtk3 x86_64 3.22.30-4.el8 @AppStream 20 M gvfs x86_64 1.36.2-6.el8 @AppStream 1.6 M gvfs-client x86_64 1.36.2-6.el8 @AppStream 4.2 M hicolor-icon-theme noarch 0.17-2.el8 @AppStream 72 k jasper-libs x86_64 2.0.14-4.el8 @AppStream 381 k jbigkit-libs x86_64 2.1-14.el8 @AppStream 107 k lcms2 x86_64 2.9-2.el8 @AppStream 390 k libXcomposite x86_64 0.4.4-14.el8 @AppStream 35 k libXcursor x86_64 1.1.15-3.el8 @AppStream 48 k libXi x86_64 1.7.9-7.el8 @AppStream 96 k libXinerama x86_64 1.1.4-1.el8 @AppStream 15 k libXrandr x86_64 1.5.1-7.el8 @AppStream 52 k libXtst x86_64 1.2.3-7.el8 @AppStream 34 k libbluray x86_64 1.0.2-3.el8 @AppStream 371 k libcdio x86_64 2.0.0-3.el8 @AppStream 811 k libcdio-paranoia x86_64 10.2+0.94+2-3.el8 @AppStream 195 k libgusb x86_64 0.3.0-1.el8 @BaseOS 115 k libosinfo x86_64 1.5.0-3.el8 @AppStream 1.0 M libtiff x86_64 4.0.9-15.el8 @AppStream 619 k libusal x86_64 1.1.11-39.el8 @AppStream 487 k osinfo-db noarch 20190611-1.el8 @AppStream 1.5 M osinfo-db-tools x86_64 1.5.0-4.el8 @AppStream 263 k python3-argcomplete noarch 1.9.3-6.el8 @AppStream 194 k python3-chardet noarch 3.0.4-7.el8 @BaseOS 904 k python3-libvirt x86_64 4.5.0-2.module_el8.1.0+248+298dec18 @AppStream 1.5 M python3-pysocks noarch 1.6.8-3.el8 @BaseOS 75 k python3-requests noarch 2.20.0-2.1.el8_1 @BaseOS 369 k python3-urllib3 noarch 1.24.2-2.el8 @BaseOS 604 k rest x86_64 0.8.1-2.el8 @AppStream 190 k virt-manager-common noarch 2.2.1-2.el8 @AppStream 4.3 M Riepilogo della transazione ========================================================================================================================================================================== Rimossi 43 pacchetti
This one was officially fixed as part of 1.6.0 release and, most likely, will be part of RHEL-8.3 / CentOS which will be released after RHEL-8.3.
(In reply to Fabiano Fidêncio from comment #11) > This one was officially fixed as part of 1.6.0 release and, most likely, > will be part of RHEL-8.3 / CentOS which will be released after RHEL-8.3. Thank you very much Fabiano!