Since gtk+-2.13, gail is included in it, so a dummy ebuild (gail-1000) was created for doing the migration. Now gail-1000 is the only version available in tree, so why isn't it removed ? All ebuilds depending on gail should depend on >=gnome-base/gt+-2.13 instead. Here is the list of ebuilds that should be modified : =x11-misc/glunarclock-0.32.4 =gnome-extra/at-spi-1.28.1 =gnome-extra/at-spi-1.26.0 =gnome-extra/at-spi-1.24.1 =gnome-extra/gtkhtml-3.28.2 =gnome-extra/gtkhtml-3.28.1 =gnome-extra/gtkhtml-3.26.3 =gnome-extra/gtkhtml-3.24.5 =gnome-extra/gtkhtml-2.11.1 =gnome-extra/gnome-media-2.26.0-r1 =gnome-extra/gnome-media-2.24.0.1-r1 =app-accessibility/gok-2.28.1 =app-accessibility/gok-2.26.0 =app-accessibility/gok-2.24.0 =gnome-base/libgnomecanvas-2.20.1.1 and then dependencies for !<gnome-base/gail-1000 should be removed in : =x11-libs/gtk+-2.18.5 =x11-libs/gtk+-2.16.6 =x11-libs/gtk+-2.14.7-r2 Reproducible: Always
technically, the same goes for scrollkeeper.
scrollkeeper is different. If a package uses old scrollkeeper method for registering its help files, then it should depend on scrollkeeper, not rarian. Once things convert to some new help system that rarian is or will provide (they were figuring things out still last time I checked), instead of relying on rarian scrollkeeper compatibility, we would also convert the dep to rarian and not before. That way we know that once nothing depends on scrollkeeper we can stop building rarian with scrollkeeper compatibility. I suppose we'll not think about splitting gail out of gtk+ anytime soon and that can go away, but not in any hurry with that. Two third of those ebuilds would be going away soon anyway with regular stale ebuild cleanup run
seems that it has been removed tonight :)
