Unreliable link speed may cause wget fail to download some of deb packages

[YOURLEGEND]

情况简介

一部分libc版本的Libc包或者libc-dbg包疑似没有下载成功，导致出现空目录现象

以下是我在使用时碰到的示例(实际下载过程的log没有保存)：

~/glibc-all-in-one/libs/2.23-0ubuntu11_amd64/.debug$ ls
libanl-2.23.so           libdl-2.23.so            libnss_dns-2.23.so       libresolv-2.23.so
libBrokenLocale-2.23.so  libm-2.23.so             libnss_files-2.23.so     librt-2.23.so
libc-2.23.so             libmemusage.so           libnss_hesiod-2.23.so    libSegFault.so
libcidn-2.23.so          libmvec-2.23.so          libnss_nis-2.23.so       libthread_db-1.0.so
libcrypt-2.23.so         libnsl-2.23.so           libnss_nisplus-2.23.so   libutil-2.23.so
libc.so.6                libnss_compat-2.23.so    libpcprofile.so
~/glibc-all-in-one/libs/2.23-0ubuntu11_amd64/.debug$ cd ..
~/glibc-all-in-one/libs/2.23-0ubuntu11_amd64$ ls
~/glibc-all-in-one/libs/2.23-0ubuntu11_amd64$

注意以上libc虽然debug库内有文件，但是libc库没有任何文件，而且因为程序是进行的目录存在性检测，需要删除该目录重新下载才有效

~/glibc-all-in-one/libs/2.23-0ubuntu11_amd64$ xclibc -d -r  2.23-0ubuntu11_amd64
[+]Successfully deleted 2.23-0ubuntu11_amd64
cp: invalid option -- '.'                                          <------------------------------------- 这里貌似也有bug，调用了RECORD函数
Try 'cp --help' for more information.
[+]restore!
~/glibc-all-in-one/libs/2.23-0ubuntu11_amd64$ xclibc -d   2.23-0ubuntu11_amd64

问题和建议解决方案

wget 问题

疑似因为下载速度过慢导致部分包被wget中断现象，建议加入支持断线重连选项，如 -c 等

以下是GPT4关于wget下载冗余处理的相关选项

Q:how to make wget download completely(when downloading process halted, trying to reconnect and download until files downloaded completely)?

A:If you're trying to make wget resilient to interruptions and want it to keep trying to download a file until it's complete, you can utilize several of its options:

--retry-connrefused: Retry if the connection is refused.

--waitretry=seconds: Wait the specified number of seconds between retries.

--timeout=seconds: Set the network timeout.

--tries=number: Set the number of retries.

-c or --continue: Resume getting a partially-downloaded file.

Here's an example that wraps these options together:


wget --retry-connrefused --waitretry=5 --read-timeout=20 --timeout=15 -t 0 -c [URL]


Here's a breakdown of the command:

--retry-connrefused: Even if the connection is refused, wget will keep trying.

--waitretry=5: wget will wait 5 seconds before the next retry.

--read-timeout=20: Set the read timeout to 20 seconds. If no data is received for more than this specified time, wget will retry.

--timeout=15: The network timeout is set to 15 seconds. If the server does not respond within this time, wget will retry.

-t 0: This tells wget to keep retrying indefinitely.

-c: If the download is interrupted, running this command again will resume from where it left off.

For very unreliable connections, you might need to adjust the retry and timeout values to be more lenient. You can also use -T as a shorthand for --timeout.

Keep in mind that this setup will have wget trying indefinitely, which might not be suitable in all scenarios. Adjust the -t option or remove it entirely if you want a finite number of retries.

log问题

由于没有目前没有简易的手段检测各个库是否下载完全，建议以下两种选择，选择其中一种即可：

• 在批量下载时进行log(校验deb文件hash或者在stderr输出错误信息打log)
• 编写脚本使得对各个目录进行完整性检测(或者文件存在的检测)，列出不完整目录

在此基础上，支持对于未下载或者漏下载的deb包进行批量下载，或者让用户一一下载未成功包

[ef4tless]

感谢你的issue，没来得及即使更新，我发现glibc-all-in-one项目的解压功能出现问题，我已经进行了修复，现在应该会解决一部分解压导致的bug。同时我也注意到了程序里的一些bug，也进行了修复。考虑到在进行大量下载时会出现中断的问题，现在进行了一些临时处理，后续再进行进一步的更新