Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 669234 - x11-libs/gtk+-3.* make at-spi optional
Summary: x11-libs/gtk+-3.* make at-spi optional
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 6 votes (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-21 20:17 UTC by Don O
Modified: 2020-09-21 18:57 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch for gtk+-3.22.19 ebuild (gtk+-3.22.19.ebuild.patch,1.30 KB, patch)
2018-10-21 20:18 UTC, Don O
Details | Diff
patch for gtk+-3.22.30 ebuild (gtk+-3.22.30.ebuild.patch,1.29 KB, patch)
2018-10-21 20:19 UTC, Don O
Details | Diff
patch for gtk+-3.24.1 ebuild (gtk+-3.24.1.ebuild.patch,1.28 KB, patch)
2018-10-21 20:19 UTC, Don O
Details | Diff
patchset for gtk+-3.22.30 to make at-spi optional (gtk+-3.22.30.atk-bridge.patch,1.82 KB, patch)
2018-10-21 20:20 UTC, Don O
Details | Diff
patch for /gtk+-3.24.22.ebuild (file_669234.txt,1.32 KB, patch)
2020-08-28 03:47 UTC, tonemgub
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Don O 2018-10-21 20:17:20 UTC
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).
Comment 1 Don O 2018-10-21 20:18:15 UTC
Created attachment 552174 [details, diff]
patch for gtk+-3.22.19 ebuild
Comment 2 Don O 2018-10-21 20:19:18 UTC
Created attachment 552176 [details, diff]
patch for gtk+-3.22.30 ebuild
Comment 3 Don O 2018-10-21 20:19:46 UTC
Created attachment 552178 [details, diff]
patch for gtk+-3.24.1 ebuild
Comment 4 Don O 2018-10-21 20:20:39 UTC
Created attachment 552180 [details, diff]
patchset for gtk+-3.22.30 to make at-spi optional
Comment 5 Don O 2018-10-21 20:21:27 UTC
The patches to source code have worked for all versions that I've tested from 3.22.19 on (with some fuzzing).
Comment 6 Don O 2018-10-22 17:05:16 UTC
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.
Comment 7 Mart Raudsepp gentoo-dev 2018-10-22 23:07:18 UTC
I'll make the eautoreconf change. Feel free to leave this bug about at-spi open for now for "official" investigation and consideration.
Comment 8 Gilles Dartiguelongue gentoo-dev 2018-10-23 10:00:59 UTC
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.
Comment 9 Don O 2018-10-23 10:52:57 UTC
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.
Comment 10 Martin Cihlář 2018-10-23 14:23:17 UTC
(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).
Comment 11 aj-lists 2018-10-23 21:35:22 UTC
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.
Comment 12 Gilles Dartiguelongue gentoo-dev 2018-10-24 11:37:25 UTC
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.
Comment 13 Martin Cihlář 2018-10-24 11:57:03 UTC
(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.
Comment 14 Don O 2018-10-24 13:09:11 UTC
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.
Comment 15 Don O 2018-10-24 13:26:10 UTC
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
Comment 16 Hanno Zysik (geki) 2018-11-11 11:44:18 UTC
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
Comment 17 Mart Raudsepp gentoo-dev 2018-11-11 13:20:38 UTC
(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.
Comment 18 pogosyan 2019-01-20 16:41:49 UTC
(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.
Comment 19 Hadrien Lacour 2020-02-15 14:05:47 UTC
Thanks a lot for this, works nicely with x11-libs/gtk+-3.24.13.
Comment 20 tonemgub 2020-08-28 03:47:00 UTC
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.
Comment 21 Gary Wong 2020-09-21 18:54:31 UTC
(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.