On 6/5/20 11:28 am, Anatol Pomozov wrote: >>> Multiplexed database/files downloads will use multiple progress bars. >>> The UI logic is quite complicated and printing error messages while >>> handling multiple progress bars is going to be challenging. >>> >>> Instead we are going to save all ALPM error messages to a list and flush >>> it at the end of the download process. Use on_progress variable that >>> blocks error messages printing. >>> >> This is going to be fun... If you have a 100 package update and your >> first mirror is down, you will end up with 100 error messages at the >> end. e.g. >> >> $ sudo ./build/pacman -Sy >> :: Synchronizing package databases... >> testing 45.4 KiB 24.5 KiB/s 00:02 [##############] 100% >> core 134.6 KiB 61.8 KiB/s 00:02 [##############] 100% >> extra 1646.0 KiB 741 KiB/s 00:02 [##############] 100% >> community-testing 621.3 KiB 468 KiB/s 00:01 [##############] 100% >> community 4.9 MiB 2.12 MiB/s 00:02 [##############] 100% >> error: failed retrieving file 'extra.db' from allanmcrae.com : The >> requested URL returned error: 404 >> error: failed retrieving file 'testing.db' from allanmcrae.com : The >> requested URL returned error: 404 >> error: failed retrieving file 'core.db' from allanmcrae.com : The >> requested URL returned error: 404 >> error: failed retrieving file 'community-testing.db' from allanmcrae.com >> : The requested URL returned error: 404 >> error: failed retrieving file 'community.db' from allanmcrae.com : The >> requested URL returned error: 404 > I believe this is the same behavior as we currently have in the latest > release. >
Yes - but the errors are spread through the output. I was thinking of an update of 100 packages, and suddenly this gets spewed out at the end. >> This is patch is fine, but we should perhaps change the output to count >> the failures from each server. > Doing aggregation like this would be a bit tricky. The error message > formatting happens at ALPM level when it calls _alpm_log() function. > _alpm_log() calls handle->logcb() with a formatted string as an > argument. So pacman has no reliable way to find out what was the error > context. Pacman's responsibility at this point is just to collect the > messages and print it without screwing up the UI. > > Thus the error aggregation need to happen in dload.c and would require > some refactoring. Of course - I was not talking about it happening in this patch. Just flagging something of future polishing. A
