Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
SDAdham opened this issue Sep 2, 2022 · 8 comments

Comments

@SDAdham
Copy link

SDAdham commented Sep 2, 2022

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

image

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
Copy link

elfring commented Sep 3, 2022

I am curious about data processing improvements in mentioned areas. 🤔

See also:
Issues with openSUSE Repos

@SDAdham
Copy link
Author

SDAdham commented Sep 3, 2022

@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
Copy link
Author

SDAdham commented Sep 3, 2022

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
Copy link
Author

SDAdham commented Sep 3, 2022

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
Copy link

elfring commented Sep 3, 2022

💭 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? 🤔

@SDAdham
Copy link
Author

SDAdham commented Sep 3, 2022

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
Copy link

pavinjosdev commented Feb 6, 2024

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
Copy link
Contributor

bzeller commented Mar 13, 2024

Duplicate of #104

@bzeller bzeller closed this as not planned Won't fix, can't repro, duplicate, stale Mar 13, 2024
@bzeller bzeller marked this as a duplicate of #104 Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants