Would it be possible to modify the ebuild for gtk+-3 series ebuilds to make at-spi (atk-bridge) as optional rather than a hard dependency along with it pulling in dbus. Once upon a time in the early 3 series it was optional then upstream removed it and no one ever tried to put it into the gentoo system. I looked up the patches and they work (from at least 3.22.19 through 3.24.1).
Created attachment 552174 [details, diff] patch for gtk+-3.22.19 ebuild
Created attachment 552176 [details, diff] patch for gtk+-3.22.30 ebuild
Created attachment 552178 [details, diff] patch for gtk+-3.24.1 ebuild
Created attachment 552180 [details, diff] patchset for gtk+-3.22.30 to make at-spi optional
The patches to source code have worked for all versions that I've tested from 3.22.19 on (with some fuzzing).
Going the other direction, I started this bug report today https://bugs.gentoo.org/669320 If that get straightened out, then the need for modifying the ebuild for atk-bridge removal would go away. Probably easier on the devs to make the ebuild problem (linked bug) behave properly as I and others can then use user patches for modifying.
I'll make the eautoreconf change. Feel free to leave this bug about at-spi open for now for "official" investigation and consideration.
The reasons for why at-spi is not optional in gtk+:3 are: * Upstream made the decision to make accessibility framework mandatory. * It is used in unittests frameworks such as dogtail. * We try not to diverge from upstream when there is no clear reason to. Avoiding dbus in the context of graphical applications was not, until now at least.
Just a couple of comments. 1. The accessibility framework is still there, atk is still pulled in. It's the at-spi (atk-bridge via dbus) that's not pulled in. 2. Not everyone uses gnome, which seems to be the driver in this case, even though it's gtk+ not gnome. I use openbox which doesn't care nor need either at-spi nor dbus. Having said that, I understand your reasoning. And as I said in the linked bug, if it's easy for me to use epatch/eapply user then I don't have a problem going that route. Thanks for your responses.
(In reply to Gilles Dartiguelongue from comment #8) > The reasons for why at-spi is not optional in gtk+:3 are: > * Upstream made the decision to make accessibility framework mandatory. > * It is used in unittests frameworks such as dogtail. > * We try not to diverge from upstream when there is no clear reason to. > Avoiding dbus in the context of graphical applications was not, until now at > least. Understandable, however since GNOME upstream has been said to have made some questionable decisions in the recent years (and this is arguably one of them) this proposal should be at least entertained. I'm not clear on what exactly changed from GTK+2 to GTK+3 to mandate the change. I'm 100% on Don O's side, there are many people who don't use GNOME and even more who have no interest in the features the at-spi2-* packages bring to the table; there are countless threads on the Web of people complaining about GTK+3 applications having started/left the daemon running even after the application has closed. I agree with diverging from upstream as little as possible. A hypothetical "accessibility" USE flag would logically have to be on by default, maybe it should also be marked as experimental (such as having a "disable-at-spi" flag that can only be enabled with ~arch, which removes the at-spi2-* functionality/dependency).
I would also very much appreciate the option to not pull in atk - it's ridiculous to force everyone to install accessibility stuff when it's not relevant; most of us run Gentoo specifically because it allows us to keep a clean system without piles of junk we don't need or want and this is a prime example.
Looks like I failed to mention this kind of change requires manpower. Not because this is a big change on its own, but because it affects a rather core package to GUI apps and unthreading every use of it might require extended work that we cannot handle. Any further help on the subject is welcome of course.
(In reply to Gilles Dartiguelongue from comment #12) Clearly, such changed always require extensive testing first (hence my suggestions in comment #10). I would certainly like to help in any way I can; I'm not much of a programmer myself but I could use my Gentoo systems to test the change since I have plenty of time on my hands. If this hypothetical change were to be announced (maybe in form of a news item, similar to the experimental 17.1 profiles) we could garner more attention to this issue and possibly more users willing to help.
I agree it requires testing. I do know that it's been applied by some people from the gentoo forum, but I don't know how many. But I've not heard of any reports of people having problems from the patch.
I started a thread on gentoo forum to let those who are interested in this patch being added, know that they might want to help with testing. https://forums.gentoo.org/viewtopic-p-8274482.html
The true issue of this bugreport seems to be for me the line from the adwaita-icon-theme package commented on the forums post: "# gtk+:3 is needed for build for the gtk-encode-symbolic-svg utility" Just like I posted on the forums thread, the tool gtk-encode-symbolic-svg could be repackaged just like dev-util/gtk-update-icon-cache. Or simply be packaged with gtk-update-icon-cache. Both handle icon processing at install phase. One patch[0] for the Gtk 3 version of gtk-encode-symbolic-svg is necessary to remove the dependency on Gdk. The Gtk 4 version can be patched similarly. [0] https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-gnome/gtk%2B/gtk-icon-utils/Remove-Gdk-dependency-from-gtk-encode-symbolic-svg.patch
(In reply to Hanno Meyer-Thurow (geki) from comment #16) > The true issue of this bugreport seems to be for me the line from the > adwaita-icon-theme package commented on the forums post: > > "# gtk+:3 is needed for build for the gtk-encode-symbolic-svg utility" > > Just like I posted on the forums thread, the tool gtk-encode-symbolic-svg > could be repackaged just like dev-util/gtk-update-icon-cache. Or simply be > packaged with gtk-update-icon-cache. Both handle icon processing at install > phase. One patch[0] for the Gtk 3 version of gtk-encode-symbolic-svg is > necessary to remove the dependency on Gdk. The Gtk 4 version can be patched > similarly. gtk-update-icon-cache exists because both gtk+:2 and gtk+:3 have it, and we didn't want to depend one of the slots on the other, in order to have it available in one copy only (as multiple same files is not possible, they collide). gtk2 does not ship a gtk-encode-symbolic-svg, so we don't need this split at this point. Maybe once we package gtk4 RCs or final (in March 2019), it has that tool too, and we need to do it for these reasons. However avoiding a gtk+:3 dep in adwaita-icon-theme is not something that is really necessary - adwaita-icon-theme ships icons for GNOME/GTK+ applications, and all these should be GTK+:3 anyways - gtk2 is deprecated. It might be nice to have, just so you could use adwaita-icon-theme icons on e.g. Plasma without any gtk+ programs at all, but that has a near zero users, and is still possible anyways - gtk+ is only a build depend, and can be depcleaned in such a situation after adwaita-icon-theme install/upgrade. I'm sorry, but having a system with gtk+2 only, without gtk3 installed at all, is not a use case we will support in any shape or form. gtk2 is deprecated, move on. Also, you can still depclean gtk3 after adwaita-icon-theme install/upgrade in such a situation as well, just like the above described case. Additionally this bug is about at-spi, NOT adwaita-icon-theme and its deps.
(In reply to Mart Raudsepp from comment #17) > (In reply to Hanno Meyer-Thurow (geki) from comment #16) > > The true issue of this bugreport seems to be for me the line from the > > adwaita-icon-theme package commented on the forums post: > > > > "# gtk+:3 is needed for build for the gtk-encode-symbolic-svg utility" > > > > Just like I posted on the forums thread, the tool gtk-encode-symbolic-svg > > could be repackaged just like dev-util/gtk-update-icon-cache. Or simply be > > packaged with gtk-update-icon-cache. Both handle icon processing at install > > phase. One patch[0] for the Gtk 3 version of gtk-encode-symbolic-svg is > > necessary to remove the dependency on Gdk. The Gtk 4 version can be patched > > similarly. > > gtk-update-icon-cache exists because both gtk+:2 and gtk+:3 have it, and we > didn't want to depend one of the slots on the other, in order to have it > available in one copy only (as multiple same files is not possible, they > collide). > gtk2 does not ship a gtk-encode-symbolic-svg, so we don't need this split at > this point. Maybe once we package gtk4 RCs or final (in March 2019), it has > that tool too, and we need to do it for these reasons. > However avoiding a gtk+:3 dep in adwaita-icon-theme is not something that is > really necessary - adwaita-icon-theme ships icons for GNOME/GTK+ > applications, and all these should be GTK+:3 anyways - gtk2 is deprecated. > It might be nice to have, just so you could use adwaita-icon-theme icons on > e.g. Plasma without any gtk+ programs at all, but that has a near zero > users, and is still possible anyways - gtk+ is only a build depend, and can > be depcleaned in such a situation after adwaita-icon-theme install/upgrade. > > I'm sorry, but having a system with gtk+2 only, without gtk3 installed at > all, is not a use case we will support in any shape or form. gtk2 is > deprecated, move on. Also, you can still depclean gtk3 after > adwaita-icon-theme install/upgrade in such a situation as well, just like > the above described case. > > Additionally this bug is about at-spi, NOT adwaita-icon-theme and its deps. You are correct that this bug is not about gtk-encode-symbolic-svg, but may I remark that we can talk about depreciation of gtk+-2 only when GIMP ceases to depend on it (incidently, I remember when GTK was standing for "GIMP ToolKit") . For many of us outside of GNOME world, GIMP is the most important GTK+ application. So there is nowhere to "move on" here.
Thanks a lot for this, works nicely with x11-libs/gtk+-3.24.13.
Created attachment 657210 [details, diff] patch for /gtk+-3.24.22.ebuild Patch works great with gtk+-3.24.22 as well, thanks! Maybe some year it can be mainstreamed.
(In reply to tonemgub from comment #20) > Patch works great with gtk+-3.24.22 as well, thanks! Maybe some year it can > be mainstreamed. I'm encouraged to see that this patch seems to be popular and maintained. It's unfortunate that upstream seems to reject this flexible approach, and for years now I've been applying workarounds eliminating gratuitous dependencies from my own systems. I've combined this modified ebuild with a couple of similar ones into an overlay repo: git://people.freedesktop.org/~gary/optdeps (with the general theme of making dependencies optional.) I'm curious to hear if any other users are interested in using and/or contributing to a collection of tweaks like this. If so, maybe we can pool them into one place to reduce duplication of effort, and perhaps get it listed on repos.gentoo.org.
Putting aside the atk-bridge dep, I believe that todays gtk3 and gtk4 packages should RDEPEND on dbus directly, as nowadays: * On wayland it's used to talk to the Settings portal to actually have some of these things work (on X11 it was setting properties on the X11 root window or something as fallback afaik) * Looks used to implement some core GtkApplication stuff (uniqueness, handover to the already running instance, etc) * Used for something related to cups printing secrets * For any persistent GSettings usage, you need dbus on Linux for dconf anyways In GTK4 accessibility supposedly doesn't use atk I knew, so I'm not sure about the at-spi2-atk dep there, but dbus itself is probably even more relied on.
Keep in mind when this was started (2018) so it's quite long in the tooth now. And keep in mind that I wasn't and still not running either gnome or kde, so my needs were much different then than now, as I've moved completely from X to wayland. I agree with matt, that modern systems rely heavily on dbus. As far as dbus being a *DEPEND, I can think of times, using gtk+ that have no need of the dbus portion. I know that the original inclusion was simply laziness on the part of the gtk devs, rather than figure out what might be truly needed for gtk+, they just threw everything that might [i]possibly[/i] be needed into it. Until I swapped out to wayland from X, I did not need either at-spi bridge or dbus for my system to run properly. And with this reply I'm removing my self from getting mail about this. Have fun, and enjoy life.
Is this useflag still available? This is what I get for latest version: $ eq u gtk+ [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for x11-libs/gtk+-3.24.41: U I + + X : Add support for X11 - - abi_x86_32 : 32-bit (x86) libraries - - broadway : Enable the GDK Broadway backend - - cloudproviders : Enable GtkPlacesSidebar to access cloud services - - colord : Use x11-misc/colord for color management in printing - - cups : Add support for CUPS (Common Unix Printing System) - - examples : Install examples, usually source code - - gtk-doc : Build and install gtk-doc based developer documentation for dev-util/devhelp, IDE and offline use + + introspection : Add support for GObject based introspection - - sysprof : Enable profiling data capture support using dev-util/sysprof-capture - - test : Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently) - - vim-syntax : Pulls in related vim syntax scripts - - wayland : Enable dev-libs/wayland backend + + xinerama : Add support for querying multi-monitor screen geometry through the Xinerama API
