On Sun, Nov 11, 2001 at 06:51:10AM -0900, Ethan Benson wrote: > On Sun, Nov 11, 2001 at 03:40:37PM -0700, Chris Tillman wrote: > > On Sun, Nov 11, 2001 at 10:48:02PM +1000, Anthony Towns wrote: > > > On Sun, Nov 11, 2001 at 07:12:01AM -0700, Chris Tillman wrote: > > > > I did submit one, albeit untested. aj said that particular patch wouldn't > > > > work correctly. I'm still unconvinced that it doesn't re-download the stuff > > > > even when theres a deb sitting there. > > > > > > So, uh, why don't you *test* it then? > > > > Yes, well I didn't feel technically up to it, I was having a very hard > > time reading the dense shell code. But it would definitely be a good > > learning experience, so I'll tackle that next. > > > > > deboostrap does *not* download things that're already there. Whatever > > > you're seeing is probably a bug, but it's not what you think it is. > > > > I'll see if I can pin it down. It's a very frustrating (bug || whatever) > > for a (slow || expensive || (slow && expensive) network user. > > fwiw in my most recent tests of debootstrap 0.15.8 i could not > reproduce the problem where it ignored existing files and started > over. the last time that i had tested that was a much older > debootstrap, perhaps pre 0.15, everything else ive used basedebs.tgz > since i don't have time to make every b-f test take 5 hours. > > also you should try with cvs (or 3.0.17 whenever that happens) > boot-floppies built with debootstrap 0.15.8, i have fixed debootstrap > and boot-floppies dialogs/info messages to make it much more clear > when its verifying a pre-downloaded .deb rather then downloading a new > one. >
That does work, now. As I was playing around with it while it was doing its thing, I saw that what was taking the time was not downloading but other stuff. During the Packages.gz downloading message, it's actually running pkgdetails for each package which it's going to be downloading. On my system, that routine was taking 10 to 30 seconds per package, so that's why it was taking 15 minutes to download Packages.gz. Actually, the download only took 20 seconds (DSL:-). So it would be a cool enhancement to have a progress bar during the pkgdetail stuff for those of us with 180 MHz machines. Then, it was really quite surprising how long the validation process was taking all by itself. (I stopped debootstrap purposely when it was about 2/3 done and restarted). I did verify the packages were not getting downloaded again (apologies due). Here's what was taking all the time (which I thought without checking it out was download time): Pkg download approx. md5sum wc -c ------ --------------- ------ ----- libc6 55 sec 15 sec 1 min 19 sec dpkg 18 sec 5 sec 25 sec I have no idea why the sums and wc take so long on that machine in the installer. Must be some effect of the reduced libraries. If I do the same operations in a booted Linux system on that machine, they take around a second or so. I also checked it in the installer system on my iMac, and it's pretty much instant there too. ls -l takes no time at all to come up with the same number as wc -c. But that's just on my machine, I'm not suggesting to change it. The job does get done eventually. -- *----------------------------------------------------------------* | .''`. | Debian GNU/Linux: <http://www.debian.org> | | : :' : | debian-imac: <http://debian-imac.sourceforge.net> | | `. `'` | Chris Tillman [EMAIL PROTECTED] | | `- | May the Source be with you | *----------------------------------------------------------------* -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
