Please do support parallel update download and consolidate retry requests into 1 at the end of the download progress about zypper HOT 6 OPEN

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

See also:
Issues with openSUSE Repos

from zypper.

@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): 

from zypper.

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.

from zypper.

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.

from zypper.

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

from zypper.

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.

from zypper.