dev-python/pycairo-1.8.8 recently added support for USE=svg but did so without a revbump. specifically: ... -IUSE="doc examples" +IUSE="doc examples +svg" ... +RDEPEND=">=x11-libs/cairo-1.8.8[svg=]" ... now, an `emerge world -Dup` aborts because i already have pycairo installed and when it was built, i had USE=svg, but it did not have IUSE=svg: emerge: there are no ebuilds built with USE flags to satisfy ">=x11-libs/cairo-1.8.8[-svg]". !!! One of the following packages is required to complete your request: - x11-libs/cairo-1.8.8 (Change USE: -svg) (dependency required by "dev-python/pycairo-1.8.8" [installed]) (dependency required by "@world" [argument]) considering i have USE=svg, this output is confusing. wth would pycairo require cairo to be built without svg support !? the only way around this is to re-emerge pycairo manually. once i do that, everything is copacetic. imo, this is a semi-common thing people do (like it or not), so portage should handle it smoothly for the sake of end users. the logic being: - package foo has new USE flag added to IUSE - package's new USE flag has a USE depend with new USE flag - if new USE flag added is enabled in the system, imply --newuse semantics for this one package only
dev-python/pycairo-1.8.8 now has IUSE="doc examples svg" (see bug #284833). (I'm in dev-portage alias.)
The code from bug 137562 (in portage-2.2_rc34) is supposed to handle stuff like this. Basically, it should work like this: 1) Pull installed dev-python/pycairo-1.8.8 into graph recurse into deps. 1) Mask installed dev-python/pycairo-1.8.8 due to unsatisfied dep. 2) Recalculate deps and pull in the latest dev-python/pycairo ebuild with current USE settings. So, were you using a version of portage earlier than 2.2_rc34 when you experienced this problem? If not, it might just need a little tweak somewhere to get it to handle this case.
*** Bug 284988 has been marked as a duplicate of this bug. ***
i'm using Portage 2.2_rc40 and both packages (cairo/pycairo) are in my world file i hit this bug today (minutes before i filed the bug)
I've just noticed that there's some special code related to USE deps that prevents the bug 137562 code from working in this case. It needs to detect whether or not the flags will change for the parent package when it decides whether or not to mask the installed package and recalculate.
This is not related to the backtracking code. Here is what happens: 1) IUSE of dev-python/pycairo changes, but on "emerge -uD world" emerge doesn't consider it for re-installation, because -N isn't given. 2) When emerge comes to the point where it wants to satisfy dev-python/pycairo's deps (>=x11-libs/cairo-1.8.8[svg=]), it checks the enabled use flags of the installed dev-python/pycairo. svg isn't in there, because it wasn't in IUSE when dev-python/pycairo was installed. This makes emerge think the svg flag is disabled. I'm not sure what the correct approach is. The obvious solutions are: 1) Don't allow such changes. 2) Don't look at the ebuild in the tree, but the ebuild in the vdb. (In reply to comment #0) > imo, this is a semi-common thing people do (like it or not), so portage should > handle it smoothly for the sake of end users. the logic being: > - package foo has new USE flag added to IUSE > - package's new USE flag has a USE depend with new USE flag > - if new USE flag added is enabled in the system, imply --newuse semantics for > this one package only > In the following I'll refer to three suggestions in the quoted comment as a, b and c. a) sounds doable. It might confuse users, because these kind of things are currently covered by -N. b) sounds like a hack. It would create a dependency between currently unrelated things (the first being "IUSE difference between ebuild and installed package" and the second "package's *DEPEND") c) doesn't catch cases with a new dep of the form: !foo? ( ... )