Demonstration, with virtuals: >>> import portage >>> portage.grab_stacked("virtuals",["/etc/make.profile"],portage.grabdict)['virtual/opengl'] ['x11-base/xfree'] >>> portage.grab_stacked("virtuals",["/var/cache/edb"],portage.grabdict)['virtual/opengl'] ['media-video/nvidia-glx', 'x11-base/xorg-x11'] >>> portage.grab_stacked("virtuals",["/etc/make.profile","/var/cache/edb"],portage.grabdict)['virtual/opengl'] ['x11-base/xorg-x11', 'media-video/nvidia-glx', 'x11-base/xfree'] Obviously, this last should be ['media-video/nvidia-glx', 'x11-base/xorg-x11', 'x11-base/xfree'] to make sense and to conform with the Portage docs. I don't mind saying this took me an age to figure out, and I didn't expect to have to go this deep into Portage internals. The culprit is in pym/portage.py @@ 824-835: for y in stuff.keys(): if not final_dict.has_key(y): final_dict[y] = stuff[y] else: for thing in stuff[y]: if thing: if thing[0] == '-': if thing[1:] in final_dict[y]: del final_dict[y][final_dict[y].index(thing[1:])] else: if thing not in final_dict[y]: final_dict[y].insert(0,thing)
Ooh. Looking at the viewcvs it seems like the whole lot of that code region has been refactored. I'll grab a recent portage 2.0.51_pre and see if that fixes things; if so I'll close this.
Oh, I forgot to say: the obvious fix is to replace for thing in stuff[y]: with for thing in stuff[y][::-1]: I guess few enough people will be affected by this that the fix isn't really needed, though.
And it does (although these "QA Notice" messages portage is throwing up are a little scary). Closing FIXED, though not too sure if this is the correct resolution (how far away is portage 2.0.51 from a public testing release?)
Reopening to mark as duplicate of bug 45468.
*** This bug has been marked as a duplicate of 45468 ***
