Bug 1262845 - RFE: provide --print-uris (or equivalent) option for DNF
RFE: provide --print-uris (or equivalent) option for DNF
Status: NEW
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Daniel Mach
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-14 09:24 EDT by Shriramana Sharma
Modified: 2018-04-08 00:57 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-21 05:44:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Shriramana Sharma 2015-09-14 09:24:23 EDT
Description of problem:

Frankly I'm thinking of migrating over to Fedora/KDE from very many years at Kubuntu. Over the years I have grown used to lots of Debianisms in package management and have learned to harness the default Debian tools to my own requirements.

I use apt-get's --print-uris (http://manpages.ubuntu.com/manpages/trusty/man8/apt-get.8.html) option very often to get a list of package URIs that apt is going to download then I download those files using my preferred download manager (aria2) at my preferred time, in sequence with other unrelated downloads to avoid overcrowding my available bandwidth etc.

Now apt-get doesn't (officially) support aria2 as a background and hence is quite slow. I was given to understand that dnf or zypper can go much faster. However my first dnf upgrade on Fedora 22 said it wanted to download 600 MB worth of packages and I said yes and went over to do other stuff and over three hours later I find that it's still sitting at the same package without any progress.

Now I'm pretty sure that the network was up all this time but in any case if I could just have an option like --print-uris for dnf to print the URIs of the packages it's going to download, then it will be much more convenient for me to streamline the downloading of these packages with that of other files.

Version-Release number of selected component (if applicable):
1.0.0
Comment 1 Radek Holy 2015-09-15 04:19:02 EDT
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).
Comment 2 Honza Silhan 2015-09-16 07:26:51 EDT
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.
Comment 3 Shriramana Sharma 2015-09-16 22:28:31 EDT
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.
Comment 4 Radek Holy 2015-09-17 05:25:18 EDT
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...
Comment 5 Honza Silhan 2015-09-21 05:44:24 EDT
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.
Comment 6 Shriramana Sharma 2015-09-22 10:58:33 EDT
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.
Comment 7 Jeff Gustafson 2016-01-20 01:16:19 EST
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!
Comment 8 Matthew Miller 2017-06-16 10:58:47 EDT
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.
Comment 9 Daniel Mach 2017-06-21 07:22:15 EDT
$ 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?
Comment 10 Matthew Miller 2017-06-21 10:39:32 EDT
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?
Comment 11 Igor Gnatenko 2017-06-21 10:41:16 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.