Bug 1262845
| Summary: | RFE: provide --print-uris (or equivalent) option for DNF | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Shriramana Sharma <samjnaa> |
| Component: | dnf | Assignee: | rpm-software-management |
| Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | mattdm, ncjeffgus, packaging-team-maint, rholy, tim.lauridsen, vmukhame |
| Target Milestone: | --- | Keywords: | Reopened, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-08-10 05:39:58 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
Shriramana Sharma
2015-09-14 13:24:23 UTC
FYI, there is a request for a --downloadonly option (the bug 1048433) which would allow you to just download the packages first and install them later. Also, you can use dnf-automatic to schedule automatic download of packages. I understand that this is not what you've requested. I'm mentioning it just in case you find it more convenient (like I do). Closing as solutions for your use case are already implemented in DNF (see comment 1). If we didn't understand your use case correctly, feel free to elaborate little more. The --downloadonly option and dnf-automatic are addressing other use cases. What I am asking for is to get the URIs so that I can feed it to my preferred downloader so it can handle the bandwidth etc correctly in balance with other downloads that may be going on. If I run two programs at the same time, either is not aware of the other and tries to hog the available bandwidth resulting in inefficiency. Granted, I could launch both sequentially, but I would still like to use my preferred downloader (aria2) as I think it is more efficient/fast than the curl backend dnf uses. Since dnf has to know the URLs anyway, I hope it would be straightforward enough to just print them out and exit. I apologize, I/we have misunderstood the motivation. FYI, DNF actually does not know the URLs. It just knows the URL of the "metalink" and the file name (and some other metadata) of the package. The underlying library librepo is responsible for choosing the best mirror, composing the URL and downloading the file. It means, BTW, that we would need some callback in the library to provide the information to you. Just FYI... The problem is that we don't know the URL from metalinks, it is taken care on lower level by librepo. If anyone shares the same use case and would like to see this feature, post a comment and you'll get higher chance to have this feature. Hello. I understand. However, while I don't know the internals of the software, it would seem that a callback is not required since the librepo doesn't need to "give back" the URLs to dnf but it can just expose an API which would just print the URLs to stdout and then exit. This used to work: yum download --url <packagename> ...but DNF doesn't support it? Count me as another person that would like to have this feature in DNF! I'd like to reopen this with another use-case: diagnostics. Our mirror network is big and volunteer-based and not always 100% in sync. It's hard to figure out what's going on in these cases, and directing users to look through debug output in dnf.librepo.log doesn't feel very friendly. I think most ideal would simply to print the URLs when using --verbose. $ dnf download --help | grep url --url, --urls print list of urls where the rpms can be downloaded $ rpm -q dnf dnf-2.5.1-1.fc26.noarch This feature seems to be present in dnf in Fedora 26. Can you confirm it works for you as expected so we can close this bug? Daniel -- yes, that's there. It doesn't help with the other use case I gave (basically, finding out where `dnf upgrade` is trying to get stuff from). Should I make that a separate RFE? The problem is: each time dnf will take packages from different URLs (because mirrors and such)... So I would prefer to close this as CANTFIX. I am closing the issue due to inactivity, difficult implementation with mirrors and due to presence of workaround with download command with the `--url` option. |