While updating world, I got the error seen under “Actual Results” below. So apparently gtk-engines-qt-1.1-r1 can’t compile and run without accessibility features in qt-gui? I understand why one would want to add such functionality. But why make it a requirement? We aren’t *all* handicapped on this planet …yet. ;) The old version (0.8-r3) worked fine without this. Apparently the source of this new version (for KDE 3.5 nonetheless. I have blocked everything KDE 4 and Gnome (where possible) is a new slot called “(1)”, with only this inside. And it’s no overlay too. Even more strange, the old slot (for the 0.8 versions) was called “(2)”. It looks as if something with the ebuilds of gtk-engines-qt went terribly wrong. Of course it’s too late to fix the old ones. But at least that new one should be reported upstream, if the accessibility can’t made optional trough fixing the ebuild. Reproducible: Always Steps to Reproduce: emerge -autv gtk-engines-qt # or “emerge -auDNtv world”, if this includes it. Actual Results: emerge: there are no ebuilds built with USE flags to satisfy "x11-libs/qt-gui:4[accessibility,dbus]". !!! One of the following packages is required to complete your request: - x11-libs/qt-gui-4.4.2-r2 (Change USE: +accessibility) (dependency required by "x11-themes/gtk-engines-qt-1.1-r1" [ebuild]) (dependency required by "world" [argument]) Expected Results: Normal update of gtk-engines-qt (with the system, if trough world update), or leave it non-updated. A partial workaround for now, is to mask x11-themes/gtk-engines-qt:1 or x11-themes/gtk-engines-qt-1.1-r1 The second one risks having the same problem when the next version arrives. And the first one has the possible problem, of blocking all ebuilds of the “(1)” slot. Both disable you from updating this thing, and everything that depends on it. Therefore it’s only a partial workaround. So am I now disabled *because* of accessibility features? How ironic. But far from the first time a false sense of social correctness has resulted in something like this ;)
Ok i am sorry but kde4 needs accessibility flag enabled, which means that every depending package will get it throught eclass. So live with it or dont use it. For your help g-e-q-1.1-r1 is used for kde4 so if you dont want it, mask it :]
Ah, Ok. Thank you. I masked it. But on the other hand, how can it even come in, when I have masked the whole KDE4-stuff, and am just doing an update? I bet it is one of those “hard dependencies” (aka. “we force it down your throat, if you want it or not”). So you go with completely ignoring that horrible mess of slots that this set of ebuilds is, and my questions about it? ;) I think, the mess with the slots of big dependency trees, is the bigges failure in portage in the last years. Masking the slot of the main kde metapackage for 4.x should mask the same slot of everything under it / everything it depends on. Or am I the only one who came up with that idea? In that case: Where can I submit my suggestion? I can write Python code too.