| 1 |
Jason Stubbs wrote: |
| 2 |
> On Saturday 26 November 2005 11:07, Marius Mauch wrote: |
| 3 |
> |
| 4 |
>>On Sat, 26 Nov 2005 00:01:15 +0900 |
| 5 |
>>Jason Stubbs <jstubbs@g.o> wrote: |
| 6 |
>> |
| 7 |
>>>The only other new thing in trunk that I know of is logging but |
| 8 |
>>>there's still a question mark over the ordering of messages... Can |
| 9 |
>>>that be resolved soon? Anything else missing? Any reasons against any |
| 10 |
>>>of the above? |
| 11 |
>> |
| 12 |
>>Resolved how? I'm not really sure I understood the original problem |
| 13 |
>>(other than listdir being underdeterministic in theory). |
| 14 |
> |
| 15 |
> |
| 16 |
> TGL suggested that all the messages go into a single file with some sort of |
| 17 |
> prefix that would then be parsed on the python side. The original order of |
| 18 |
> messages could then be maintained. However, seeing as there needs to be no |
| 19 |
> compatibility with the temporary files it could wait for later anyway. |
| 20 |
|
| 21 |
a) haven't seen a patch for it, so no clue about how complex it is code |
| 22 |
wise and b) I generally dislike any markup/parsing in the temporary |
| 23 |
files. I'd rather get it out as-is now and incorporate any feedback |
| 24 |
later. As you said this "interface" doesn't have to be compatible, also |
| 25 |
I intended to add a general "might change"-note for elog in the release |
| 26 |
notes. |
| 27 |
|
| 28 |
>>- the pycrypto hash additions (for .54) |
| 29 |
> |
| 30 |
> This is only useful if the vote goes in favour of adding further hash types to |
| 31 |
> Manfiest, right? If the vote goes that way I've got no issues with it, but if |
| 32 |
> it doesn't it would essentially be dead code. |
| 33 |
|
| 34 |
Well, the vote was more for the SHA1 change actually as that's the one |
| 35 |
triggering the size increase. The pycrypto stuff itself doesn't do |
| 36 |
anything really, it would just make the size increase more apparent. |
| 37 |
|
| 38 |
>>- Killing off auto-use+USE_ORDER? |
| 39 |
> |
| 40 |
> Yep, I'd really like to see this one gone too. We should probably state the |
| 41 |
> intention on -dev first though as there might be a lot of people against it. |
| 42 |
|
| 43 |
Well, Spanky liked the suggestion ;) |
| 44 |
|
| 45 |
>>- the recursive grab* functions I just posted (for .54) |
| 46 |
> |
| 47 |
> Needs a small amount of work (/etc/portage/package.mask/foo/bar would break |
| 48 |
> it) but I like the general idea. |
| 49 |
|
| 50 |
How would it break? |
| 51 |
|
| 52 |
>>- integration of set modules, either as emerge targets (requires |
| 53 |
>>serious gutting of emerge) or a first-class atoms (semantically |
| 54 |
>>tricky, no clue about implementation yet) |
| 55 |
> |
| 56 |
> I'm working on this with my refactoring. Defininately a post-.54 thing unless |
| 57 |
> you want to quickly hack it into getlist()? |
| 58 |
|
| 59 |
Don't think so given that offhand I don't even know what getlist() does ... |
| 60 |
|
| 61 |
Oh, btw, two things that are in trunk but weren't listed in your |
| 62 |
original mail: |
| 63 |
- the rewritten versioning code (including the cvs and mult-suffix |
| 64 |
enhancements) |
| 65 |
- finally killing of the stupid "masked by -*" message |
| 66 |
|
| 67 |
Marius |
| 68 |
-- |
| 69 |
gentoo-portage-dev@g.o mailing list |
Archives