On Monday 12 December 2005 18:30, Duncan wrote:
> For example,  if repository-id forms a part of the path and we define path
> parsing now, then we are effectively defining legal characters for
> repository-id now.

This is only of concern to portage developers.

> That's an entirely different glep, far out of scope and 
> reaching into other people's territory, limiting how that might be
> implemented by defining a portion of the id-scope in an entirely unrelated
> glep.

No need for a glep as far as portage support goes anymore than Ciaran needs a 
glep to change or add syntax highlighting in vim.

> Given how heated I've seen GLEP discussion get (and I'm not saying that's
> /bad/, just a fact), I really can't blame Ciaran for attempting to keep
> the scope of the proposal, and therefore the debate, down to exactly what
> he's aiming to accomplish, without ending up getting into an entirely
> /different/ debate about how he's limiting the future flexibility of the
> multiple repo implementation.

There doesn't need to be a debate. This whole proposal doesn't care about 
portage compatibility whatsoever and it's exactly this style of thinking that 
slows down portage development (which everybody loves to complain about so 
much).

> Once there's a concrete proposal there to work with, then and only then, 
> he's saying (from my viewpoint), is it appropriate for consideration in 
> relation to the news proposal. Don't unnecessarily tie the two together, 
> complicating life for both.  Let each be argued on its merits separately, 
> and when/if multiple repo is actually close enough to deployment that 
> there's some actual rules to work with, /then/ worry about fixing this to 
> match.      

As I said already, there will immediately be a bug asking for overlay support. 
Portage already supports multiple in a form whether anybody likes it or not.
How they are supported and how they will change should be of no concern to the 
glep. What should be of concern is establishing a robust API between the 
readers and portage such that future changes won't cause breakage.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Reply via email to