Ok, here's the situation (all ebuilds in question are in the x11 overlay)
x11-base/xorg-server-1.5.3 has this atom in PDEPEND only :
input_devices_evdev? ( >=x11-drivers/xf86-input-evdev-2.1.0 )
Now, on my test system, here's what portage tells me :
# emerge -1 xorg-server -p
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] x11-drivers/xf86-input-evdev-2.1.0 [2.0.7]
[ebuild R ] x11-base/xorg-server-1.5.3 USE="-tslib%" INPUT_DEVICES="-tslib%"
Shouldn't the order be reversed? Am I missing something?
Feel free to slap me silly if this is not a bug :)
It makes PDEPEND more useful if it behaves more like RDEPEND, for cases like bug #180045. However, for the particular case that you've given, it's certainly more optimal to merge xorg-server first since xf86-input-evdev has xorg-server in DEPEND.
Zac, any updates on this? I'm currently planning to stabilize xorg to 1.5.3-r1 from 184.108.40.206-r6. If users have to rebuild/update their drivers only once, that would save us from major bug spam.
I need to try and reproduce the case reported in comment #0 because there's already some code to account for cases like this and I'm not sure why the order didn't come out more optimal.
As for the 1.3.x to 1.5.x upgrade, this issue can only affect drivers which are compatible with both 1.3.x and 1.5.x. For example, it won't affect xf86-input-evdev upgrades since this driver typically requires an xorg-server version >1.3.x in DEPEND. This is different from the case reported in comment #0, where xorg-server-1.5.x already happened to be installed (and thus the build time dependency was already satisfied).
Created attachment 180634 [details, diff]
fix sub-optimal merge order
If this patch is saved as /tmp/merge_order.patch, then it can be applied as follows:
patch /usr/lib/portage/pym/_emerge/__init__.py /tmp/merge_order.patch
The attached patch fixes some similar cases, but not the one reported in comment #0. There's still a remaining issue...
This is fixed in svn r12612. The changes to the merge order algorithm should also account for many common cases of bug #199856, but does not necessarily solve all possible cases of that bug.
This is fixed in 2.2_rc24 which is in package.mask. I'll close this bug when it's also released in 220.127.116.11.
This is released in 18.104.22.168.