SUMMARY ------- Providing an HTTP[S] URI serving a `.flatpak` file to the `--local-filename` flag of `plasma-discover-6.3.2-1.fc41.x86_64` results in an error, despite it functioning with a `file:///` URI pointing to the same file (when stored locally). Considering that `flatpak-1.16.0-1.fc41.x86_64`, OSTW's `zypper`, and FC41's `dnf5-5.2.10.0-2.fc41.x86_64` all support HTTP URIs as arguments to their installation parameters, Discover should support this. STEPS TO REPRODUCE ------------------ 1. Install `plasma-discover-6.3.2-1.fc41.x86_64`. 2. Provide an HTTP[S] URI serving a `.flatpak` file to its `--local-filename`. OBSERVED RESULT --------------- If accessed via `firefox-136.0-2.fc41.x86_64`, I see a valid response: > ~~~HTTP > HTTP/2 200 > content-type: application/octet-stream > last-modified: Mon, 11 Mar 2024 04:36:49 GMT > etag: "0x8DC4184DE4008CC" > server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0 > x-ms-request-id: 5af19293-b01e-003f-0239-9129f6000000 > x-ms-version: 2025-01-05 > x-ms-creation-time: Mon, 11 Mar 2024 04:36:49 GMT > x-ms-blob-content-md5: zmnaghRa6M/tXsmxRbDXBg== > x-ms-lease-status: unlocked > x-ms-lease-state: available > x-ms-blob-type: BlockBlob > content-disposition: attachment; filename=naps2-7.4.0-linux-x64.flatpak > x-ms-server-encrypted: true > via: 1.1 varnish, 1.1 varnish > fastly-restarts: 1 > accept-ranges: bytes > date: Sun, 09 Mar 2025 21:31:56 GMT > age: 328 > x-served-by: cache-iad-kcgs7200031-IAD, cache-lon420123-LON > x-cache: MISS, HIT > x-cache-hits: 0, 1 > x-timer: S1741555917.611357,VS0,VE1 > content-length: 20338640 > X-Firefox-Spdy: h2 > ~~~ However, if provided as an argument to the `--local-filename` flag, it errors: > ~~~QML > org.kde.plasma.libdiscover: OdrsReviewsBackend: Fetch ratings: false > adding empty sources model QStandardItemModel(0x56493d02af10) > qrc:/qt/qml/org/kde/discover/qml/LoadingPage.qml:3:1: QML LoadingPage: Created graphical object was not placed in the graphics scene. > qrc:/qt/qml/org/kde/discover/qml/BrowsingPage.qml:17:1: QML BrowsingPage: Created graphical object was not placed in the graphics scene. > KNSCore::ResultsStream(0x56493eeb82e0) Finishing KNSCore::StaticXmlProvider(0x7f735c014ad0) 0 > ~~~ EXPECTED RESULT --------------- It should the same as it would if the file had been supplied via a `file://` URI. SOFTWARE/OS VERSIONS -------------------- 1. ~~~sh #!/usr/bin/env sh kinfo ~~~ 1. > ~~~YAML > Operating System: Fedora Linux 41 > KDE Plasma Version: 6.3.2 > KDE Frameworks Version: 6.11.0 > Qt Version: 6.8.2 > Kernel Version: 6.13.5-200.fc41.x86_64 (64-bit) > Graphics Platform: Wayland > Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor > Memory: 30.4 GiB of RAM > Graphics Processor 1: AMD Radeon RX 5700 > Graphics Processor 2: AMD Radeon Graphics > ~~~ ADDITIONAL INFORMATION ---------------------- I expect that this isn't a matter of locality versus externality, since `file://` URIs support hostnames other than `localhost` (the default for `file:///`). Rather, it merely isn't yet designed to support alternative schemas. Considering that Dolphin utilises KIO to support myriad methods of acquiring content via HTTP[S], FTP[S], and WebDav, et cetera, Dolphin should be able to without reinventing much. I've reported this to the PK backend, because I believe that this affects RPM files, too.
Stepping back for a second - could you help articulate your use case for using Discover (a GUI tool) from the command-line in this situation, rather than the CLI package managers that you listed?
(In reply to John Kizer from comment #1) > could you help articulate your use case for using Discover (a GUI tool) from the command-line in this situation, rather than the CLI package managers that you listed? Automation scripts for myself. It's a lot easier, in *some* situations, to utilise Discover in the stead of 12 different command-line package management interfaces, when I'm going to run a script across multiple OSes. That's why I utilised a flatpak reference file in the examples. I expect you're now thinking, "just use `flatpak` then", but that would be using another PM CLI, whereas Discover already supports every backend possible. Considering that PackageKit doesn't appear to support `.flatpak` files, I'd have to stay this highly abstracted to not at least delegate to `pkcon` and `flatpak`. It's definitely niche, since just downloading a file beforehand isn't a terrible amount of work. Though, a better error message would be useful regardless, if it's undesirable, considering that all the lower-level alternatives aforereferenced support HTTP URIs (albeit, ironically, not file URIs, unlike Discover).
I'll defer to the Plasma maintainers, but I think the catch here is that the existing Discover command-line interface options are generally for CLI equivalents of functions performed by the Discover GUI - ex. "Here's an Appstream URI, find that application in the configured repos" or "Here's a locally downloaded file, show and install it". For what it's worth...as far as I know, there's no current GUI function in Discover for inputting a web address, downloading whatever file is served from there, treating it like a locally downloaded file and installing. That's a process with some inherent security/integrity risks that don't exist in Appstream URIs pointing to managed repositories, and that are assumed by the user if they go and download a file from the web to be installed - so my guess is that the request might be a tough fit for the intended functionality and scope of Discover.
(In reply to John Kizer from comment #3) > That's a process with some inherent security/integrity risks that don't exist in Appstream URIs In that case, would I be able to provide an AppStream URI to it, and have that work? If so, how does one discover what URI applies to what package? That seems like a better solution overall for *most* cases.
Discover supports appstream:// and flatpak:// URIs; you should be able to use one of those. I'm closing this bug report now because it's practically unreadable due to the unnecessary formatting that isn't rendered by Bugzilla. Writing bug reports this way makes them extremely taxing to read; please open new bug reports using human-readable formatting and no giant info dumps of unneeded information. Thanks for understanding.
(In reply to Nate Graham from comment #5) > Discover supports appstream:// and flatpak:// URIs; you should be able to use one of those. Yes – the previous triage assignee mentioned that, and it seems ideal. However, how does one discover that? (Is such a question outside the purview of this thread?) > I'm closing this bug report now because it's practically unreadable due to the unnecessary formatting that isn't rendered by Bugzilla. I thought using something designed to be standard but human-readable would help – I tried pretty hard to find something that seemed to fulfill that. Do you have a writing standard for Bugzilla reports? It'd be difficult with absolutely no markup syntax (unlike GitLab, etc). Apologies. > Writing bug reports this way makes them extremely taxing to read; please open new bug reports using human-readable formatting I was under the impression that you'd just copy this into a Markdown renderer. > no giant info dumps of unneeded information. ...which bits? It's a little difficult to act on advice when it's vague.
(In reply to Roke Julian Lockhart Beedell from comment #6) > Do you have a writing standard for Bugzilla reports? It'd be difficult with absolutely no markup syntax (unlike GitLab, etc). Apologies. Looking at others reports, it looks like removing header markers (letting them just be standard paragraph text) and code indicators would work, because I see a lot of usage of URI bibliographies to ensure that they don't render the content actually unreadable. (In reply to Nate Graham from comment #5) > s practically unreadable due to the unnecessary formatting that isn't rendered by Bugzilla Could it be you're seeing what I do at GitHub on my smartphone – backticks rendering *over* text? [^1] If so, that makes a lot more sense. I've been using a monospaced font for so long that I forgot about it. [^1] https://github.com/orgs/community/discussions/144767#discussion-7493333
Fancy Markdown formatting that Bugzilla doesn't support displaying on the web page is unnecessary and distracting for people reading bug reports there (which is to say everyone; nobody copies and pastes the text into a text editor window to read it). No need for things like: ~~~HTTP 1. > ~~~YAML Additional underlines below the header labels In general, with bug reports, you want to describe how the bug happens with clear steps, and the environment you're using using a dump of the `kinfo` command, and anything else that seems relevant to the issue itself. Additional information beyond that tends to be a distraction and makes it difficult to find the important stuff. Thanks.
(In reply to Nate Graham from comment #8) Yeah. After reading some very kind responses to a question I posed about this, I realize how different it must look to all you using variable-width fonts... [^1] Real apologies. Is it alright if I re-file the affected bugs? I'll try my best to keep them simple. Thanks for taking the time to triage them. [^1]: https://talk.commonmark.org/t/4955/4
Thanks, I appreciate seeing it from our perspective. :) Go ahead. However for this one I think we should keep it closed since there are alternatives to accomplish what you want to do, which is something Discover was not designed to support.