Please do support parallel update download and consolidate retry requests into 1 at the end of the download progress

[SDAdham]

Problem

I update opensuse daily, but today I received > 3k new updates. the Zypper upgrade is very slow considering that there are no multithreading. Ain't that a bit too much? I'm stuck from using the OS for > hour

For such occasions, an improvements to the updater to update in parallel would be great, the worst part is that I really ahve to keep an eye, it's a habit that every 30 packages or something, i get this error

Feature request

• Please allow parallel update download for faster download progress instead of downloading updates individually and keep waiting long times on connection open/close
• Allow the zypper to collect all those packages that it failed to download and then it would offer to retry in 1 single action rather everytime it fails, it stops everything and waits for an input. Update is something to work in the background and shouldn't really take forever and rely on user input every 5 minutes.

PLEASE HELP...

[elfring]

I am curious about data processing improvements in mentioned areas. :thinking:

See also: Issues with openSUSE Repos

[SDAdham]

@elfring , my assumption of the suggestion, it would be like this:

Retrieving: xrefresh-debuginfo-1.0.7-2.2.x86_64.rpm ................................................................................................................[error]
Download (curl) error for 'https://download.opensuse.org/debug/tumbleweed/repo/oss/x86_64/xrefresh-debuginfo-1.0.7-2.2.x86_64.rpm':
Error code: Curl error 16
Retrieving: xrefresh-debuginfo-1.0.7-2.2.x86_64.rpm ................................................................................................................[error]
Timeout exceeded when accessing 'https://download.opensuse.org/debug/tumbleweed/repo/oss/x86_64/xrefresh-debuginfo-1.0.7-2.2.x86_64.rpm'.
Retrieving: xrefresh-debuginfo-1.0.7-2.2.x86_64.rpm ................................................................................................................[error]
Download (curl) error for 'https://download.opensuse.org/debug/tumbleweed/repo/oss/x86_64/xrefresh-debuginfo-1.0.7-2.2.x86_64.rpm':
Error code: Curl error 92
Abort, retry all, retry individually, ignore all or ignore individually? [a/r/ri/i/ii/...? shows all options] (a): 

[SDAdham]

Considering that it works multithreading in downloading, multiple packages may fail at the same time, multiple may succeed at the same time. Consolidating and grouping error messages together would make sense where user may choose to either retry all, retry individually (here we retry each individually - no parallel behaviour, or we memorise user's choices on each package and then go in parallel), ignore all or ignore individually, where it would have the same behaviour but different action.

[SDAdham]

it may also make sense if we display the choices but never stop the background downloads, user may choose response accordingly, if retry is chosen then we put the package back into the queue of downloading. But in the event of abort, then this aborts the downloads immediately.

But for the sake of best user experience, i would prefer my previous comment.

[elfring]

:thought_balloon: I imagine that the representation of mentioned queues will become challenging because of involved dependency chains or even forests.

Will any experiences be reused from decision trees? :thinking:

[SDAdham]

Not really, during the installation, those dependencies can be re-asked for if they do not exist or not downloaded to be downloaded. It shouldn't be complicated.

[pavinjosdev]

Quite an old issue, putting this here if @SDAdham or anyone searching for parallel downloads ends up here as I did. I have a simple project that does parallel refreshing of repos and downloads: https://github.com/pavinjosdev/zypperoni

Installation is still slow, but that can only be safely performed by zypper itself after the async changes are merged, hopefully soon.

[bzeller]

Duplicate of #104