Bug 1317564 - dnf download: not operating if too many packages provided to the command line
Summary: dnf download: not operating if too many packages provided to the command line
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-14 15:01 UTC by Ali Akcaagac
Modified: 2016-03-29 13:24 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-03-29 13:24:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
test case hack with comps.xml processing (1.51 KB, text/plain)
2016-03-14 15:01 UTC, Ali Akcaagac
no flags Details
test case 2 hack with comps.xml processing (1.55 KB, text/plain)
2016-03-14 15:22 UTC, Ali Akcaagac
no flags Details

Description Ali Akcaagac 2016-03-14 15:01:50 UTC
Created attachment 1136190 [details]
test case hack with comps.xml processing

Urgent!

Packages within Fedora 24 / RH are starting to adapt the "extended" or "complex" dependency stuff that *yum* can't handle yet. At least the current version available for Fedora 22.

Sadly one of our use cases require dealing with pre-downloaded packages in a different directory on a different mounted system.

Problems we are stuck in:
1) dnf download still can't deal with groups but has a --downloaddir.
2) dnf install <group> --downloadonly exists but doesn't support --downloaddir.
3) yum doesn't support the complex dependency.

We are now stuck in a blocking situation and don't know howto solve the use case for the time being. And the "complex" dependency stuff started to show up in Fedora 22 and RH.

I started with an *idea* this morning.

The idea was to get the comps.xml files from Fedora git. Parsing the packages of the groups and applying the list to:

lists="list with a couple of hundret of packages"

dnf download ${lists} --downdir ~/Downloads --resolve

This would be a *walk around* or *hack* for the moment. This would free us from using yum and gives us the time until 1) or 2) might show up one time.

Sady the list is too long and dnf download aborts without reporting back. We need the possibility to apply at least 3000 - 4000 packages to the command line and have it --resolve and download.

Please find attached my work in progress use case hack! You can use this test case for improvement.

Please help! We are stuck in a situation where we can't go further nor back! We rely on package downloading!

Comment 1 Ali Akcaagac 2016-03-14 15:22:21 UTC
Created attachment 1136193 [details]
test case 2 hack with comps.xml processing

This one is working slightly better.

Comment 2 Honza Silhan 2016-03-29 13:24:29 UTC
We will add `--downloaddir` option for your use case. This is already tracked. The limitation of number of items parsed as CLI arguments could be in argparser or Python itself.


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