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 1EnmoN-0004nR-EZ for garchives@archives.gentoo.org; Sun, 18 Dec 2005 00:54:04 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBI0rFTR022069; Sun, 18 Dec 2005 00:53:15 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 jBI0pUSH026093 for ; Sun, 18 Dec 2005 00:51:31 GMT Received: from [10.3.1.19] (helo=barracuda2.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1Enmls-0001CJ-7K for gentoo-dev@lists.gentoo.org; Sat, 17 Dec 2005 19:51:29 -0500 X-ASG-Debug-ID: 1134867086-1122-253-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 642D597E3F for ; Sat, 17 Dec 2005 19:51:26 -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 jBI0pE5j022384 for ; Sun, 18 Dec 2005 00:51:14 GMT Date: Sat, 17 Dec 2005 16:51:05 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org X-ASG-Orig-Subj: Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates Subject: Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates Message-ID: <20051218005104.GE22142@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> <20051218001430.0d78fe4b@snowdrop.home> 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="J4XPiPrVK1ev6Sgr" Content-Disposition: inline In-Reply-To: <20051218001430.0d78fe4b@snowdrop.home> 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.6392 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Archives-Salt: 099c1c8b-5e13-4d1d-99f5-8c4cb2fc7382 X-Archives-Hash: 00ace12080413e6518dc7e1102a95ee3 --J4XPiPrVK1ev6Sgr Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 18, 2005 at 12:14:30AM +0000, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 15:33:18 -0800 Brian Harring wr= ote: > | On Wed, Dec 14, 2005 at 09:54:06PM +0000, Ciaran McCreesh wrote: > | > Well, if Portage ever gets multiple repository support, then news > | > clients can be updated to handle it. The GLEP says that already. > | Care to clarify how that transition is going to occur? > | > | 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). >=20 > 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. Transitioning from single news.unread to N is going to break clients=20 that expect a single. As I said, you're going to break stuff- and you're building it into=20 your glep out of (aparent) stubborness. What do you want, another glep amending yours with that one little=20 detail? Or someone just gets off their ass and tweaks your glep, gets=20 another glep #, and stops the pointless arguing with you and pushes=20 a competing glep? The news glep crosses several groups, collaboration here is required,=20 meaning *listen* to the folk you're trying to command. Otherwise the=20 glep *will* go nowhere no matter how much noise you make. > 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. Standard ascii, same rules required for glep31. > | 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. >=20 > 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... It's distributed via the portage tree, it's updated by portage, the=20 check for new news items is *via* portage, and check for news items=20 prior to merging is done by portage. If that truly was your intention, you failed in it.. It's bound to=20 portage, despite the rhetoric. > | 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. >=20 > 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. I'll remind you that portage devs have stated this is required for=20 your damn glep. Iow, collaboration here is required- work out the api=20 that you need that fits in with what we need, instead of wasting our=20 time arguing over whether you should do it or not. > 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... There's no asking here; you're pushing a glep, we've stated in it's=20 current form constrains *our* efforts long term. Word games suck, instead of playing them you *should* be trying to=20 address the concerns- iow, what do you *explicitly* need from portage,=20 > Especially since you've said "we're not doing it the way you think it > should work"... Where have I stated that? My statements thus far about multi repo=20 were in reference to a glep that missed the target. Provide quotes please, or get back to nailing down exactly what you=20 need portageq wise so we can state "do it this way, and we'll shut=20 up". > | 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). >=20 > 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? Stated it to cut off any angle of "waah, can't go that route,=20 portageq calls are to slow". Something your glep doesn't clarify and I want nailed down in stone=20 (since at your request we are being explicit here), is how the=20 'package manager' is going to track news items that are marked as=20 unread already, further the news.skip file. Basically... you're the glep author/champion, implementing the portage=20 modifications are your responsibility (we may help, but it's your job=20 to do it). Since this proposal *is* complicating portage, hand waving=20 of the sort "implementation is not specified by this GLEP" I want=20 nailed down. You want us to nail everything down for our request, I'd like you to=20 do the same (especially since we're stuck maintaining whatever you=20 propose/create). ~harring --J4XPiPrVK1ev6Sgr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDpLJ4vdBxRoA3VU0RAi0GAKCW0oYVx21eU4nS0GtTa3ue/Dl4PgCgwK5A tODD0XJLpfJvmkzqaCmRT+E= =IxhV -----END PGP SIGNATURE----- --J4XPiPrVK1ev6Sgr-- -- gentoo-dev@gentoo.org mailing list