On Sun, Dec 18, 2005 at 12:14:30AM +0000, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 15:33:18 -0800 Brian Harring <[EMAIL PROTECTED]> wrote: > | 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 > | 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.
Transitioning from single news.unread to N is going to break clients that expect a single. As I said, you're going to break stuff- and you're building it into your glep out of (aparent) stubborness. What do you want, another glep amending yours with that one little detail? Or someone just gets off their ass and tweaks your glep, gets another glep #, and stops the pointless arguing with you and pushes a competing glep? The news glep crosses several groups, collaboration here is required, meaning *listen* to the folk you're trying to command. Otherwise the 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 > | the proposal- especially since your proposal is intrinsically portage > | 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... It's distributed via the portage tree, it's updated by portage, the check for new news items is *via* portage, and check for news items prior to merging is done by portage. If that truly was your intention, you failed in it.. It's bound to 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 > | screwed over by a feature. Something along the lines of... > | > | 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. I'll remind you that portage devs have stated this is required for your damn glep. Iow, collaboration here is required- work out the api that you need that fits in with what we need, instead of wasting our 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 current form constrains *our* efforts long term. Word games suck, instead of playing them you *should* be trying to address the concerns- iow, what do you *explicitly* need from portage, > 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 were in reference to a glep that missed the target. Provide quotes please, or get back to nailing down exactly what you need portageq wise so we can state "do it this way, and we'll shut up". > | If it's too slow, I'd suggest since it's your proposal, looking for a > | method to batch up the calls (modularization of portageq would be > | required, which is available in the dead ebd branch already). Tricks > | 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? Stated it to cut off any angle of "waah, can't go that route, portageq calls are to slow". Something your glep doesn't clarify and I want nailed down in stone (since at your request we are being explicit here), is how the 'package manager' is going to track news items that are marked as unread already, further the news.skip file. Basically... you're the glep author/champion, implementing the portage modifications are your responsibility (we may help, but it's your job to do it). Since this proposal *is* complicating portage, hand waving of the sort "implementation is not specified by this GLEP" I want nailed down. You want us to nail everything down for our request, I'd like you to do the same (especially since we're stuck maintaining whatever you propose/create). ~harring
pgpeRXyuRY7ku.pgp
Description: PGP signature
