From: "Walter Dnes" <waltdnes@waltdnes.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] accelerate emerge
Date: Tue, 28 Feb 2006 17:27:20 -0500 [thread overview]
Message-ID: <20060228222720.GC1261@waltdnes.org> (raw)
In-Reply-To: <44032353.4080208@mid.message-center.info>
On Mon, Feb 27, 2006 at 05:05:39PM +0100, Alexander Skwar wrote
> El Nino wrote:
>
> > is there a way to accelerate the fetching part of emerge
> > by using prozilla or some other tool?
>
> I never quite understood the sense in those tools.
>
> Why should "prozilla or some other tool" make the
> download be faster? When I download something with
> wget, or watch emerge invoking wget, it's always
> maxing out the saturation of the line.
I have a different interpretation. Assume I'm doing an
emerge --deep --update --world
I've set my ADSL router-modem to log off after 15 minutes. The
sequence of events is something like...
1) emerge wants to download a package, so it attempts to connect to a
server, taking several seconds to wake up my ADSL router-modem
2) emerge downloads a big package, taking a few minutes to do so
3) emerge spends the next half hour building the big package, during
which time the modem-router logs off
4) emerge finally finishes building the package, and wants to work on
the next one... GOTO 1
I could run a short script
#!/bin/bash
emerge --deep --update --world --fetchonly
emerge --deep --update --world
...but I'd like to get an emerge going on the 1st package as soon as
it's finished downloading, whilst having the downloads of all the other
packages continue in a separate thread. When the 1st build is finished,
check whether the 2nd package has been downloaded. If not, wait. Then
build the 2nd package... etc, etc.
The best way to describe it is as a --fetchonly emerge that launches a
separate emerge as each individual package is finished downloading. The
"build" emerges should be serialized, i.e. only one build running at a
time, because a package may depend on the immediately preceding package.
--
Walter Dnes <waltdnes@waltdnes.org> In linux /sbin/init is Job #1
My musings on technology and security at http://tech_sec.blog.ca
--
gentoo-user@gentoo.org mailing list
next prev parent reply other threads:[~2006-02-28 22:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-27 15:49 [gentoo-user] accelerate emerge El Nino
2006-02-27 16:00 ` Boris Fersing
2006-02-27 16:39 ` El Nino
2006-02-28 6:06 ` Zac Slade
2006-02-27 21:43 ` Ralph Slooten
2006-02-27 16:05 ` Alexander Skwar
2006-02-27 17:27 ` Daniel da Veiga
2006-02-27 17:39 ` Hans-Werner Hilse
2006-02-27 18:32 ` Dave Nebinger
2006-02-28 22:27 ` Walter Dnes [this message]
2006-02-28 22:55 ` Iain Buchanan
2006-02-28 23:25 ` Mike Owen
2006-02-28 23:42 ` Boyd Stephen Smith Jr.
2006-02-28 23:50 ` Iain Buchanan
2006-03-01 3:17 ` Michael A. Smith
2006-03-01 4:11 ` Vladimir G. Ivanovic
2006-02-28 23:42 ` Boyd Stephen Smith Jr.
2006-03-01 3:15 ` Michael A. Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060228222720.GC1261@waltdnes.org \
--to=waltdnes@waltdnes.org \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox