From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1Er3ea-0007tC-Ms for garchives@archives.gentoo.org; Tue, 27 Dec 2005 01:29:29 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBR1SfT9028744; Tue, 27 Dec 2005 01:28:41 GMT Received: from cubert.e-centre.net (morbo.e-centre.net [66.154.82.3]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBR1Pat0005194 for ; Tue, 27 Dec 2005 01:25:36 GMT Received: from [10.3.1.19] (helo=barracuda2.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1Er3ap-0006n5-Sq for gentoo-dev@lists.gentoo.org; Mon, 26 Dec 2005 20:25:35 -0500 X-ASG-Debug-ID: 1135646735-15605-945-0 X-Barracuda-URL: http://10.3.1.19:8000/cgi-bin/mark.cgi Received: from et-pdx-2.site.stayonline.net (unknown [65.200.64.131]) by barracuda2.stayonline.net (Spam Firewall) with ESMTP id 5492478EC4 for ; Mon, 26 Dec 2005 20:25:35 -0500 (EST) Received: from nightcrawler ([172.16.1.202]) by et-pdx-2.site.stayonline.net (8.12.6/8.12.6) with ESMTP id jBR1PM5j029873 for ; Tue, 27 Dec 2005 01:25:22 GMT Date: Mon, 26 Dec 2005 17:25:34 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org X-ASG-Orig-Subj: Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46) Subject: Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46) Message-ID: <20051227012533.GE5809@nightcrawler.e-centre.net> References: <9e83288a0512261611v6861e351tb75367c7a30e264e@mail.gmail.com> <20051227002930.482c3f31@snowdrop.home> <20051227005934.286d5deb@snowdrop.home> <1135645649.7410.42.camel@localhost> <46059ce10512261712p61bcdc54i1010d2c52f1fe9b9@mail.gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cHMo6Wbp1wrKhbfi" Content-Disposition: inline In-Reply-To: <46059ce10512261712p61bcdc54i1010d2c52f1fe9b9@mail.gmail.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by Barracuda Spam Firewall at stayonline.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=4.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.6644 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Archives-Salt: 9a8d8f5d-d8dc-4c22-817c-50f7e181e183 X-Archives-Hash: 26d7229fe0509e84a66387acc8d13647 --cHMo6Wbp1wrKhbfi Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 26, 2005 at 08:12:03PM -0500, Dan Meltzer wrote: > On 12/26/05, Lares Moreau wrote: > > On Tue, 2005-12-27 at 00:59 +0000, Ciaran McCreesh wrote: > > > On Tue, 27 Dec 2005 01:45:00 +0100 Stefan Schweizer > > > wrote: > > > | That will increase the sync time for all of our users - can we plea= se > > > | keep this info out of the sync-tree? > > > > > > Learn to use the rsync exclude list. > > > > > I think the point was that the 'average' user needs to pull it as well > > and has _no_ use for it. > > > > There are already complaints about syncs taking to long. >=20 > The complaints was about the cache, not about the actual sync time Complaints about both actually- try sync'ing on a crap connection. =20 Rsync doesn't scale well the larger the dataset gets (the fact it=20 still performs well is a testament to it being mostly a damn fine=20 tool). We've got at least a 2.4mB overhead just for doing=20 filelist/chksum transfers; that's not getting into pulling the=20 _actual_ updates. > This is what, maybe the equivilent of a new ebuild once, and a -rX any > time somethings changed? It won't effect much at all and end up being > a lot more helpful (and quickly implemented) than waiting around for > someone to write a web database and pushing that through. Quicker balanced against proper; debate right now is if it's the=20 proper place to do this (thus address that concern) :) > We have metadata.xml's, why not use them? We have ebuilds, why don't we stick it there? Arguement doesn't work=20 well there ;) (No I'm not advocating tagging this into ebuilds btw). ~harring --cHMo6Wbp1wrKhbfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDsJgNvdBxRoA3VU0RAt9YAKDY2481abtsEq2hLOWp1LuhIjowRwCgyG4m ONNAGEjcwXJkhgqW6LRixk8= =lFyP -----END PGP SIGNATURE----- --cHMo6Wbp1wrKhbfi-- -- gentoo-dev@gentoo.org mailing list