On Wed, Dec 14, 2005 at 09:54:06PM +0000, Ciaran McCreesh wrote: > On Wed, 14 Dec 2005 13:48:45 -0800 Zac Medico <[EMAIL PROTECTED]> wrote: > | I wish you'd reconsider, because I was looking forward to multiple > | repository support. > > 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).
If you're not going to do N repo, state so in the glep, state that it
_will_ break down the line, and that the issue while known, are being
ignored despite portage developers concerns. Only fair the council
knows the exact details, that and it made clear that this was known
when proposed and ignored.
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.
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.
Integration for that is pretty damn simple from our side of things,
and you get the major blocker of your news glep resolved (meaning it
has a chance of actually passing).
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).
~harring
pgpQEwhHt8ZlE.pgp
Description: PGP signature
