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 1EnmHf-0003v4-Kn for garchives@archives.gentoo.org; Sun, 18 Dec 2005 00:20:16 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBI0J92d025060; Sun, 18 Dec 2005 00:19:09 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBI0Edob011629 for ; Sun, 18 Dec 2005 00:14:39 GMT Received: from 82-41-57-20.cable.ubr08.edin.blueyonder.co.uk ([82.41.57.20] helo=snowdrop.home) by smtp.gentoo.org with esmtpa (Exim 4.54) id 1EnmCE-0000ZC-EN for gentoo-dev@lists.gentoo.org; Sun, 18 Dec 2005 00:14:38 +0000 Received: from localhost.home ([127.0.0.1] helo=snowdrop.home) by snowdrop.home with esmtp (Exim 4.54) id 1EnmC9-0001sI-Do for gentoo-dev@lists.gentoo.org; Sun, 18 Dec 2005 00:14:33 +0000 Date: Sun, 18 Dec 2005 00:14:30 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates Message-ID: <20051218001430.0d78fe4b@snowdrop.home> In-Reply-To: <20051217233318.GC22142@nightcrawler.e-centre.net> References: <20051211013550.66bfd7d2@snowdrop.home> <200512140911.51446.jstubbs@gentoo.org> <20051214005202.34958472@snowdrop.home> <200512142109.02622.jstubbs@gentoo.org> <20051214180221.5136cf94@snowdrop.home> <43A0933D.1010402@gmail.com> <20051214215406.33fed83f@snowdrop.home> <20051217233318.GC22142@nightcrawler.e-centre.net> X-Mailer: Sylpheed-Claws 2.0.0-rc1 (GTK+ 2.8.9; i686-pc-linux-gnu) 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; boundary="Sig_y4Kf9D_p=BuVKfAp=T+CvJW"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: f32e9022-bb54-4feb-9462-d5f22b3d1347 X-Archives-Hash: 4e9c951980146a70d37a1f96ed15436f --Sig_y4Kf9D_p=BuVKfAp=T+CvJW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 17 Dec 2005 15:33:18 -0800 Brian Harring wrote: | On Wed, Dec 14, 2005 at 09:54:06PM +0000, Ciaran McCreesh wrote: | > On Wed, 14 Dec 2005 13:48:45 -0800 Zac Medico | > wrote: | > | I wish you'd reconsider, because I was looking forward to multiple | > | repository support. | >=20 | > Well, if Portage ever gets multiple repository support, then news | > clients can be updated to handle it. The GLEP says that already. |=20 | Care to clarify how that transition is going to occur? |=20 | Your proposal, if you know a roadblock is coming down the line I=20 | expect it to be documented in the glep (with potential suggestions | how to minimize the horkage). It'll probably just be a case of updating news clients to query Portage somehow for a list of repository IDs and using appropriately named news files. Hard to say for sure without details of how exactly multiple repository support will work though -- for example, if you're going to allow fancy characters in repository names then some kind of name mangling standard will need to be defined. | If you're going to create and dump a mess on us, I expect it to be in=20 | the proposal- especially since your proposal is intrinsically portage=20 | bound. There's very little that's Portage bound. As originally requested, I've tried to keep as much as is reasonably possible *out* of Portage... | Thing that's daft out of all of this time wasting is that what's | being asked of you is a couple of portageq calls so that we're not=20 | screwed over by a feature. Something along the lines of... |=20 | portageq get_repo_id path # helper method of getting repo_id for a | path (dar) portageq match root atom [repo-id] # method of limiting | matching of vdb to a specific source repo | portageq newsdir repo_id # get the absolute news path for said id. You're asking me to guess how Portage multiple repository support will work, and then ask for a bunch of changes to Portage to support appropriate dummy functions. Unless you're prepared to commit yourselves to saying "multiple repository support will work like $blah", I'm not going to even think about asking you to restrict yourselves to a particular implementation... Especially since you've said "we're not doing it the way you think it should work"... | If it's too slow, I'd suggest since it's your proposal, looking for a=20 | method to batch up the calls (modularization of portageq would be=20 | required, which is available in the dead ebd branch already). Tricks=20 | of that sort are easily implemented, and don't require specs and | gleps (just requires someone to do a minor bit of work). That's not likely to be a major performance hit... We're not expecting the user to have more than a few repositories, are we? --=20 Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm --Sig_y4Kf9D_p=BuVKfAp=T+CvJW Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDpKno96zL6DUtXhERAl5JAJwPSnME2L0s7wpIh92sgUE1dDmW+ACeJV1Y lxl+EsrQ4UBu2/6JK/H9UlU= =wLw1 -----END PGP SIGNATURE----- --Sig_y4Kf9D_p=BuVKfAp=T+CvJW-- -- gentoo-dev@gentoo.org mailing list