I have 2 machines on the sad end of dialup connections that will likely never see a successful glibc update because their dialup connections don't stay up and stable long enough to fetch glibc-common. As an example [root@bp6 up2date]# ls -ltr /var/spool/up2date/glibc-common-2.2.4-27.i386.* -rw-r--r-- 1 root root 554561 Jul 29 01:03 /var/spool/up2date/glibc-common-2.2.4-27.i386.hdr -rw-r--r-- 1 root root 8962048 Jul 30 10:51 /var/spool/up2date/glibc-common-2.2.4-27.i386.rpm so it's made it most of the way through downloading the package. But, if I run up2date again: Retrieving selected packages... glibc-2.2.4-27.i686.rpm: ########################## Done. glibc-common-2.2.4-27.i386. 1 k/sec, 01:39:41 rem. and sure enough, I can kiss that progress from over an hour of download attempt goodbye :( [root@bp6 up2date]# ls -ltr /var/spool/up2date/glibc-common-2.2.4-27.i386.* -rw-r--r-- 1 root root 554561 Jul 29 01:03 /var/spool/up2date/glibc-common-2.2.4-27.i386.hdr -rw-r--r-- 1 root root 28672 Jul 30 10:57 /var/spool/up2date/glibc-common-2.2.4-27.i386.rpm No wonder my dialup machines never update after I schedule actions for them :-/ Oh, and technically this is a RHL 7.2 machine, but AFAICT this is still an issue with the existing limbo2 although I'll confirm that later today
whoops, tossing down to low/enh and i know this may be non-trivial given the xml-rpc nature of what's going on, but checking for the file existing and sending the current size (as an offset of where to start, ala ftp or doing a range like http or whatever) seems doable, i hope.
Current versions of up2date (fedora and rhel3) will attempt to recontinue an incomplete download.