Re: #103302 ask permission before erasing /var/cache/apt/archives
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 tillman@azstarnet.com |
| `- | May the Source be with you |
*----------------------------------------------------------------*
Reply to: