| Summary: | Support HTTP URIs as arguments to the `--local-filename` parameter. | ||
|---|---|---|---|
| Product: | [Applications] Discover | Reporter: | Roke Julian Lockhart Beedell <4wy78uwh> |
| Component: | PackageKit | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | wishlist | CC: | aleixpol, john.kizer, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.3.2 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| URL: | https://discuss.kde.org/t/discovers-local-filename-flag-should-support-external-uris-too/12857?u=rokejulianlockhart | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Roke Julian Lockhart Beedell
2025-03-09 21:47:30 UTC
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. |