On Saturday 26 November 2005 11:07, Marius Mauch wrote:
> On Sat, 26 Nov 2005 00:01:15 +0900
> Jason Stubbs <[EMAIL PROTECTED]> wrote:
> > The only other new thing in trunk that I know of is logging but
> > there's still a question mark over the ordering of messages... Can
> > that be resolved soon? Anything else missing? Any reasons against any
> > of the above?
>
> Resolved how? I'm not really sure I understood the original problem
> (other than listdir being underdeterministic in theory).

TGL suggested that all the messages go into a single file with some sort of 
prefix that would then be parsed on the python side. The original order of 
messages could then be maintained. However, seeing as there needs to be no 
compatibility with the temporary files it could wait for later anyway.

> > What's on the map for after that? There's a few things listed on the
> > new (still unreleased?) project index and I'm looking to get the
> > dependency stuff refactored and moved out of emerge.. What are the
> > shortterm goals?
>
> - the pycrypto hash additions (for .54)

This is only useful if the vote goes in favour of adding further hash types to 
Manfiest, right? If the vote goes that way I've got no issues with it, but if 
it doesn't it would essentially be dead code.

> - Manifest2 verification support (need the GLEP first so the format is
> sanctioned). Technically it's complete, just generation is still
> unfinished. (so a "maybe" for .54 depending on the timeframe)

Again, depends on -dev.

> - Killing off auto-use+USE_ORDER?

Yep, I'd really like to see this one gone too. We should probably state the 
intention on -dev first though as there might be a lot of people against it.

> - the recursive grab* functions I just posted (for .54)

Needs a small amount of work (/etc/portage/package.mask/foo/bar would break 
it) but I like the general idea.

> - addition of auxget/metascan tools (could be for .54)

No qualms.

> - integration of set modules, either as emerge targets (requires
> serious gutting of emerge) or a first-class atoms (semantically
> tricky, no clue about implementation yet)

I'm working on this with my refactoring. Defininately a post-.54 thing unless 
you want to quickly hack it into getlist()?

--
Jason Stubbs

-- 
gentoo-portage-dev@gentoo.org mailing list

Reply via email to