Jason Stubbs wrote:
> On Saturday 26 November 2005 11:07, Marius Mauch wrote:
> 
>>On Sat, 26 Nov 2005 00:01:15 +0900
>>Jason Stubbs <jstubbs@g.o> 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.

a) haven't seen a patch for it, so no clue about how complex it is code 
wise and b) I generally dislike any markup/parsing in the temporary 
files. I'd rather get it out as-is now and incorporate any feedback 
later. As you said this "interface" doesn't have to be compatible, also 
I intended to add a general "might change"-note for elog in the release 
notes.

>>- 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.

Well, the vote was more for the SHA1 change actually as that's the one 
triggering the size increase. The pycrypto stuff itself doesn't do 
anything really, it would just make the size increase more apparent.

>>- 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.

Well, Spanky liked the suggestion ;)

>>- 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.

How would it break?

>>- 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()?

Don't think so given that offhand I don't even know what getlist() does ...

Oh, btw, two things that are in trunk but weren't listed in your 
original mail:
- the rewritten versioning code (including the cvs and mult-suffix 
enhancements)
- finally killing of the stupid "masked by -*" message

Marius
-- 
gentoo-portage-dev@g.o mailing list