Bug 1698845
| Summary: | osinfo-detect needs gvfs | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Martin Pitt <mpitt> |
| Component: | libosinfo | Assignee: | Daniel Berrangé <berrange> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 29 | CC: | berrange, cfergeau, dac.override, fidencio, germano.massullo, zeeshanak |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libosinfo-1.4.0-3.fc30 libosinfo-1.2.0-7.fc29 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-04-27 21:24:57 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Martin Pitt
2019-04-11 11:05:17 UTC
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! |