Bug 250020 – emerge updates packages in PDEPEND first

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Rémi Cardona (RETIRED) 2008-12-06 11:42:01 UTC]

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 :)

Thanks

[Comment 1 Rémi Cardona (RETIRED) 2008-12-06 11:42:37 UTC]

better summary...

[Comment 2 Zac Medico 2008-12-06 19:11:08 UTC]

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.

[Comment 3 Rémi Cardona (RETIRED) 2009-01-19 14:16:30 UTC]

Zac, any updates on this? I'm currently planning to stabilize xorg to 1.5.3-r1 from 1.3.0.0-r6. If users have to rebuild/update their drivers only once, that would save us from major bug spam.

Cheers :)

[Comment 4 Zac Medico 2009-01-19 19:13:03 UTC]

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

[Comment 5 Zac Medico 2009-02-02 01:18:58 UTC]

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

[Comment 6 Zac Medico 2009-02-02 01:35:20 UTC]

The attached patch fixes some similar cases, but not the one reported in comment #0. There's still a remaining issue...

[Comment 7 Zac Medico 2009-02-14 22:11:22 UTC]

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.

[Comment 8 Zac Medico 2009-03-10 09:26:32 UTC]

This is fixed in 2.2_rc24 which is in package.mask. I'll close this bug when it's also released in 2.1.6.8.

[Comment 9 Zac Medico 2009-03-13 20:40:04 UTC]

This is released in 2.1.6.8.