Created attachment 240624 [details] accessibility/at-spi2-core: make dependency on dbus optional Since atk has been merged into at-spi2-core, all ports that used to be dependent on atk automatically gets dependency on devel/dbus. The attached patch introduces new option to accessibility/at-spi2-core port: ATKONLY. If set, only ATK itself would be built, for which dbus is not required. Tested on FreeBSD 13.2-STABLE stable/13-n254654-aaca677fee21 with the latest ports tree from git. Regards, Dmitry. P.S. IMHO, it's unfair to push such controversial "software" as dbus, systemd, etc. of that ilk upon everyone's throat, like Linux people like to do.
Linking a related bug report #269963, "x11-toolkits/gtk30: Depends on accessibility/at-spi2-core despite unsetting ATK_BRIDGE": https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269963
Upstream literally describes themselves as "Base DBus XML interfaces for accessibility, the accessibility registry daemon, and atspi library." Unfortunately, except for less feature-rich window managers and exactly one desktop environment, DBus is a fact of life in open source desktops, and life is often not fair.
(In reply to Charlie Li from comment #2) You are right, Charlie. But I believe that giving users a choice is always a GOOD THING. Those who do not use desktop environments would appreciate having something like the ATKONLY option provided by the patch. May I ask what DE did you mean by "exactly one desktop environment"?
(In reply to Dmitry Pryakhin from comment #3) > May I ask what DE did you mean by "exactly one desktop environment"? Lumina, but that's besides the point. Many individual desktop programs also require DBus to function at all, even if the underlying desktop environment or window manager does not. Agree that choice is a good thing. However, this has a very high maintenance cost and certainly no external-to-us support, with effectively guaranteed breakage on every update. Upstream have made their intentions clear that DBus is not separable here.
(In reply to Charlie Li from comment #4) I do not propose to remove devel/dbus from the ports tree. :) Even with the ATKONLY option set (and it is OFF by default) nothing prevents users from installing and using dbus with other ports. I think nothing could break if we allow advanced user to change the defaults (those are supposed to know what they are doing). The patch is simple enough.
Upstream has made clear that they do not intend to provide ATK separate from dbus. However, the patch that Dmitry has provided here demonstrates pretty conclusively that they *can* be separated. It further demonstrates that there are downstream users who *want* this separation, who are willing to do the work to implement it, and who are interested in sharing the result of that work with other users. The question about maintenance cost seems misplaced since there are already users who are opting to pay that cost on an ongoing basis. If Dmitry's patch is not included in the ports tree officially, I will still be applying it or something very much like it locally. I will still be doing the work to keep it working with new versions. I'm hardly unique in this regard. So, given that this work will already be happening, is the FreeBSD ports tree the appropriate place for users to share it? (And if not, what *is* the appropriate venue?)
(In reply to Dmitry Pryakhin from comment #5) > I think nothing could break if we allow advanced user to change the defaults Less seasoned users will also find the option and toggle it for the same reason of trying to shed "random" dependencies. They then take up space on various communication mediums (including upstream, where getting laughed out of the room can be expected) trying to figure out why their desktop is broken whilst justifying their pilot errors. > The patch is simple enough. It's not about how simple it may be now, but rather if it is sustainable. This includes both the patch itself and any aforementioned support threads. (In reply to Corey Halpin from comment #6) Nothing stopping you from keeping stuff locally.
(In reply to Corey Halpin from comment #6) In my opinion the only way this will sensibly land in port is if you can convince upstream to carry an option for dbus in their meson file. I.e. you need to take this up with upstream. That way it can be cleanly mapped in the ports tree, without any maintainer burden. mfg Tobias
(In reply to Tobias C. Berner from comment #8) I've contacted upstream. They are willing to consider adding an `atk_only` build option to accommodate this use case. I shall work with them on that and follow up here afterward.
Created attachment 240679 [details] with pkg-message
pkg-message to the rescue. I have amended the patch by including the pkg-message-atkonly file, which is displayed upon installation if the ATKONLY option is set. Any suggestions as to what exactly this message should look like are welcome. Also changed the description from "Build only ATK, no dbus dependency" to "Build only ATK library", which is less encouraging. :)
(In reply to Corey Halpin from comment #9) > I've contacted upstream. They are willing to consider adding an `atk_only` build option to > accommodate this use case. I shall work with them on that and follow up here afterward. Excellent! How do you plan to proceed? By opening an issue or merge request at https://gitlab.gnome.org/GNOME/at-spi2-core? I could send you (or upload here) patch against the at-spi2-core-2.46.0 sources that adds the "atkonly" meson option (usage: 'meson setup -Datkonly=true').
(In reply to Dmitry Pryakhin from comment #12) > How do you plan to proceed? By opening an issue or merge request at https://gitlab.gnome.org/GNOME/at-spi2-core? Yes, exactly. > I could send you (or upload here) patch [...] I've already constructed such a patch and revised your patch to the port to take advantage of it, but thank you. At this point, I've verified that my patch and the revised port still builds correctly and passes `poudriere testport` with the default options (i.e. leaving dbus enabled). There's no reason it should make a difference, but I feel it important to verify that fact. I'm currently waiting for a `poudriere bulk` run that builds all the ports I use with my revisions and ATKONLY set so that I can test several applications and verify that they continue to build and function as expected. This will take a while; firefox is one of them. After that is complete I'll create the issue on gitlab.gnome.org and also ping upstream to ask if there is any specific text they would like included in pkg-message for users who enable this option.
FYI, my `poudriere` tests all passed and the PR has been submitted to upstream. Currently waiting to hear back. (In reply to Charlie Li from comment #4) > [...] and certainly no external-to-us support, [...] I'd be willing to join the desktop@ team and take responsibility for keeping ATKONLY (and ATK_BRIDGE) working on future updates, and to take point on any FreeBSD bugs associated with those options.
Created attachment 240884 [details] Proposed patch My patch to the meson files was just merged upstream: https://gitlab.gnome.org/GNOME/at-spi2-core/-/merge_requests/131 Attached is a patch for the port that includes the above and modifications to the port to make use of the new meson option.
(In reply to Corey Halpin from comment #15) Good work :) Can you pull the patch in via PATCH_SITES/PATCHFILES, or does it not directly apply? mfg Tobias
Created attachment 240885 [details] Proposed patch using PATCH_SITES/PATCHFILES Good call on PATCH_SITES/PATCHFILES. Attached revision uses that instead.
(In reply to Corey Halpin from comment #17) Looks good to me. Tested with the ATKONLY option on and off.
Created attachment 241055 [details] Proposed patch, including update to 2.48.0 Upstream has made a new release, 2.48.0, which includes the atk_only meson flag along with some doc fixes. The attached pulls in that version and so no longer requires PATCH_SITES/PATCHFILES. The attached passes `poudriere testport` both with default options and with ATKONLY.
(In reply to Corey Halpin from comment #19) @antoine, could you take the 2.48.0 update for an exp-run? mfg Tobias
Exp-run looks fine
Is there anything I can be doing to help move this forward?
(In reply to Corey Halpin from comment #22) No, you've done all the necessary bits, I'll commit it later tonight.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=eab8f495bafac666c5abad491e8e353d50df5da0 commit eab8f495bafac666c5abad491e8e353d50df5da0 Author: Corey Halpin <chalpin@cs.wisc.edu> AuthorDate: 2023-04-15 18:52:07 +0000 Commit: Tobias C. Berner <tcberner@FreeBSD.org> CommitDate: 2023-04-16 00:29:41 +0000 accessibility/at-spi2-core: update to 2.48.0 What's new in at-spi2-core 2.48.0: * Add a "atk-only" build option. This allows atk to be built without libdbus installed, but it does not build libatspi or the atk bridge. * Fix some typos in the documentation. The atk-only support was added upstraem by Corey Halpin Reported by: Dmitry Pryakhin <graahnul.grom@ya.ru> PR: 269996 Exp-run by: antoine accessibility/at-spi2-core/Makefile | 11 +++- accessibility/at-spi2-core/distinfo | 6 +- accessibility/at-spi2-core/pkg-plist | 104 +++++++++++++++++------------------ 3 files changed, 63 insertions(+), 58 deletions(-)
Committed. Thanks.