From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30885 invoked from network); 14 Oct 2004 16:52:00 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 14 Oct 2004 16:52:00 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CI8pc-0002Nc-E6 for arch-gentoo-dev@lists.gentoo.org; Thu, 14 Oct 2004 16:52:00 +0000 Received: (qmail 10600 invoked by uid 89); 14 Oct 2004 16:52:00 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 3660 invoked from network); 14 Oct 2004 16:51:59 +0000 From: Luke-Jr To: Roman Gaufman Date: Thu, 14 Oct 2004 16:51:52 +0000 User-Agent: KMail/1.7.1 References: <20041012223725.6c42698a@snowdrop.home> <200410141630.32933.luke-jr@utopios.org> <921ad39e04101409351dd72779@mail.gmail.com> In-Reply-To: <921ad39e04101409351dd72779@mail.gmail.com> Cc: gentoo-dev@lists.gentoo.org IM-Address: luke-jr@jabber.org Public-GPG-Key-URI: http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xD53E9583 Public-GPG-Key: 0xD53E9583 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart16638539.CrB9HlIiJS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410141652.00388.luke-jr@utopios.org> Subject: Re: [gentoo-dev] A few modest suggestions regarding tree size X-Archives-Salt: 38c8f98c-1f0d-48dd-8b87-ae7c8affee69 X-Archives-Hash: f74c109947b4e2f1bf984a3fc79e6c42 --nextPart16638539.CrB9HlIiJS Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 14 October 2004 4:35 pm, Roman Gaufman wrote: > On Thu, 14 Oct 2004 16:30:29 +0000, Luke-Jr wrote: > > On Thursday 14 October 2004 2:49 pm, Ciaran McCreesh wrote: > > > On Thu, 14 Oct 2004 07:43:11 -0700 Mark Dierolf wrote: > > > | I've been watching this discussion as far as tree size, and i'm > > > | suprised nobody has brought the idea of on-demand downloading yet. > > > > > > Nobody has mentioned it because it has been discussed and dismissed as > > > unworkable several times before. > > > > It's quite workable. Every binary distro does it. From what I can see, > > Portage devs just don't see as much a benefit since the tree is much > > smaller than, for example, an entire copy of all binary packages Debian > > provides. > > Huh? -- name 1 binary distribution that does that? -- all of the ones > I tried fetch a list of available packages -- which is exactly what > the portage tree provides. Why would they need a list of available packages? Such a list is useful *on= ly*=20 to the user. apt-get, ipkg, and urpmi are going to know the package name=20 beforehand. Figuring out the version might be an issue, but nothing that=20 can't be solved simply by including a PHP (in the case of HTTP fetching) to= =20 choose the latest version and include the name in a header. > > > On Thursday 14 October 2004 3:14 pm, Patrick Lauer wrote: > > > So you only have to rsync the dependency info. You save maybe 50% > > > traffic, but need some ebuild servers that will be hit by millions of > > > small requests for single ebuilds. No thanks. > > > > Actually, you don't even need to sync that. Simply download the primary > > ebuild, read the dep info, download the next one, etc. Most modern > > versions of file transfer protocols (HTTP and FTP, at least; don't know > > about rsync) support multiple transfers in a single connection. > > How would it know what ebuild to fetch exactly? --- just think about > that for a second. ebuild doesn't deal with dependencys anyway, AFAIK. emerge would need the=20 fetching functionality and could figure out the name based on (originally)= =20 the user's specification and (for deps) the DEPEND contents themselves.=20 Portage *already* needs to know what the name of the package is anyway. On Thursday 14 October 2004 4:41 pm, Georgi Georgiev wrote: > The part where the HTTP and FTP internals get handled by portage > internally, instead of handling them to an external program like wget, > are the reason why the idea was dismissed as unworkable several times > before. Not really a good excuse. HTTP isn't an overly complicated protocol. Includ= ing=20 the fetching functionality also has other advantages, such as one less=20 program to depend on (and thus one fewer that can be broken and screw up=20 Portage). =2D-=20 Luke-Jr Developer, Utopios http://utopios.org/ --nextPart16638539.CrB9HlIiJS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBbq6wZl/BHdU+lYMRAgIXAJ91j/9GClYCiYL7fRn8YiF7ol5B1gCfTS3f SIKDauLfnf8jN1EV5Xio2fA= =Krcr -----END PGP SIGNATURE----- --nextPart16638539.CrB9HlIiJS--