Suppose I want to merge following packages: latest gtk+, but older version of glib. We know, that gtk+ depends on glib and glib-2.2.1-r1 is sufficiently new for gtk+-2.2.1-r1. emerge --pretend --oneshot --emptytree =x11-libs/gtk+-2.2.1-r1 =dev-libs/glib-2.2.1-r1 Output contains following interesting lines (in order): [ebuild N ] dev-libs/glib-2.2.2 [ebuild N ] x11-libs/gtk+-2.2.1-r1 [ebuild N ] dev-libs/glib-2.2.1-r1 It means, that required version glib is installed _AFTER_ gtk+. In this particular case it does not break anything, but principially it's bad - in case that required older version has different soname, it can potentially break gtk+.
No i think this is expected behaviour, in case you give seperate emerge options they will be processed seperatly and in order afaik. So first processed is gtk+, which has no restraints and next you pick a lower glib then the one gtk+ depsearch comes up with. Since you know gtk needs glib, you should have put the deps in the right order in the first place : 'ACCEPT_KEYWORDS=~x86 emerge --pretend --oneshot --emptytree =dev-libs/glib-2.2.1-r1 =x11-libs/gtk+-2.2.1-r1' which results in the behaviour you would like to see. I'm sure you could break stuff like this, but you are deliberatly trying to. Portage should then always check of every installed package if it depends on the lib updated(downgraded) and maybe even rebuild (downgrade) toplevel packages as needed. But i don't think these sort of safety precautions is a) needed b) worth the time it takes currently . There is some responsibility on the user side to know what he/she is messing with and take the problems that come from it. Anyway bug-wranglers, this is in essence a portage problem. Please close or reassign as you see fit ( i think this is a problem we are aware of and it isn't necessary to file as a new bug ). As a last note, there are many known deficiencies in portage, bringing them up without a solution (code) isn't helping much.
closing
*** This bug has been marked as a duplicate of 1343 ***
