From: Eli Schwartz <eschwartz93@gmail.com>
To: gentoo-dev@lists.gentoo.org
Cc: gnome@gentoo.org, xfce@gentoo.org, binhost@gentoo.org
Subject: [gentoo-dev] [PATCH 0/5] Fixing automagic dependencies on gtk[wayland,X],
Date: Sun, 23 Jun 2024 13:35:46 -0400 [thread overview]
Message-ID: <20240623173646.3368935-1-eschwartz93@gmail.com> (raw)
There is a bug in how gtk 3 and gtk 4 are built against by other
packages. GTK supports optionally enabling X and wayland support -- when
you do so, the ABI of GTK changes.
It is historically common for X11 packages to check for a macro provided
by GTK that says "built with X11 support". This goes back to the days
when X11 was the only backend shipped with GTK, and the main use of the
macro was to check whether to use X11 or rather to use, say, the win32
or Quartz (macOS) backends. The pattern has continued now that Linux has
two backends.
The result of this is that many packages really need to support their
own IUSE="X wayland" (because they can conditionally build code for
that) and also need to make sure that USE flag is actually respected.
Failure to do this means that when rebuilding GTK with different USE
flags, all applications linking to GTK need to be rebuilt too, but
portage doesn't know that.
It also means that binhosts -- such as the one officially hosted by
Gentoo -- have bad binaries that don't actually match the packages users
have installed. This is particularly bad since it breaks expectations
and is quite hard to debug. This has hit people a bunch of times when
trying to install the xfce desktop environment, in particular.
There are a couple possible solutions that have been considered, both by
me and others.
- simply demand upstream software implements configure options allowing
automagic dependencies to be selected in src_configure. Advantage:
every software should be doing this!!! Disadvantage: they currently do
not and demanding they do it doesn't actually mean they are doing it.
We can't just refuse to fix ebuilds that are broken, because it's
upstream's job to fix it.
- bind packages tightly to whether gtk is built with wayland, via
gtk[wayland=]. Advantage: metadata is always valid, and all builds of
the package which have wayland symbols also depend on wayland support.
Disadvantage: users have to toggle USE="wayland" on all packages at
the same time, and cannot build libxfce4ui without wayland support,
then enable wayland for gtk, without rebuilding.
- package.use.force gtk[wayland]. Advantage: nobody can rebuild gtk
without part of its ABI, so other packages always have the symbols
they need. Disadvantage: nobody can rebuild gtk without functionality
they don't use.
- adopt new functionality in EAPI 9. Currently we have slot
dependencies, which PMS carves out as a carefully scoped case where it
performs delayed metadata lookup at the time of building a package,
and updates RDEPEND values in place for the built package (to write
out the exact slot value being built against). A similar trick could
be used to expand "?" and "=" USE dependencies to also support looking
up the value of the USE that was built against, e.g.
RDEPEND="
x11-libs/gtk+:3[X:?,wayland:?]
"
meaning that building, say, libxfce4ui on a system with gtk+[wayland]
installed would propagate that dependency, but building it on a system
without a wayland-enabled gtk+ would not require any specific build of
gtk+. Advantage: packages could accurately model how they were built.
Disadvantage: any fix that requires "wait for new EAPI to be agreed on
and implemented" isn't a practical solution to current problems today.
- What I propose in this patchset. Hack a custom gentoo feature into the
GTK headers. GTK normally behaves exactly as it's supposed to
upstream, but we add the ability to pass a define via `append-cflags`
that makes the GTK headers tell an outright lie and claim its API
doesn't exist. Which is what we want -- we want packages to be able to
compile *as if* GTK wasn't built with support for a given backend.
This disables the automagic as if option 1 (implementing configure
options) was carried out. Advantage: automatically support proper
control of features. Disadvantage: requires patching GTK and
then still adding workarounds for each package that needs it.
Bug: https://bugs.gentoo.org/624960 (gtk ticket)
Bug: https://bugs.gentoo.org/680496 (future EAPI)
Bug: https://bugs.gentoo.org/873520 (libxfce4ui, some discussion on options)
Bug: https://bugs.gentoo.org/927952 (wxGTK)
Bug: https://bugs.gentoo.org/865659 (gtk-vnc)
PR: https://github.com/gentoo/gentoo/pull/37259
Eli Schwartz (5):
gui-libs/gtk: add a "poison" macro support to disable X/wayland
net-libs/gtk-vnc: prevent automagically building against
gtk[X,wayland]
x11-libs/wxGTK: prevent automagically building against gtk[X,wayland]
xfce-base/libxfce4ui: prevent automagically building against
gtk[wayland]
dev-libs/libportal: prevent automagically building against
gtk[X,wayland]
...0.7.1.ebuild => libportal-0.7.1-r1.ebuild} | 14 +++++++----
...-poison-macro-to-hide-GDK_WINDOWING_.patch | 25 ++++++++++---------
gui-libs/gtk/gtk-4.12.5-r1.ebuild | 7 ++++++
...-4.12.5-r1.ebuild => gtk-4.12.5-r2.ebuild} | 9 ++++++-
...gtk-4.14.4.ebuild => gtk-4.14.3-r1.ebuild} | 7 ++++++
...gtk-4.14.3.ebuild => gtk-4.14.4-r1.ebuild} | 7 ++++++
...c-1.3.1.ebuild => gtk-vnc-1.3.1-r1.ebuild} | 12 ++++++---
profiles/features/big-endian/package.use.mask | 1 +
....2.1-r4.ebuild => wxGTK-3.2.2.1-r5.ebuild} | 10 +++++---
...8.6.ebuild => libxfce4ui-4.18.6-r1.ebuild} | 11 +++++---
10 files changed, 74 insertions(+), 29 deletions(-)
copy dev-libs/libportal/{libportal-0.7.1.ebuild => libportal-0.7.1-r1.ebuild} (83%)
copy {x11-libs/gtk+ => gui-libs/gtk}/files/0001-gdk-add-a-poison-macro-to-hide-GDK_WINDOWING_.patch (86%)
copy gui-libs/gtk/{gtk-4.12.5-r1.ebuild => gtk-4.12.5-r2.ebuild} (94%)
rename gui-libs/gtk/{gtk-4.14.4.ebuild => gtk-4.14.3-r1.ebuild} (96%)
rename gui-libs/gtk/{gtk-4.14.3.ebuild => gtk-4.14.4-r1.ebuild} (96%)
copy net-libs/gtk-vnc/{gtk-vnc-1.3.1.ebuild => gtk-vnc-1.3.1-r1.ebuild} (76%)
copy x11-libs/wxGTK/{wxGTK-3.2.2.1-r4.ebuild => wxGTK-3.2.2.1-r5.ebuild} (95%)
copy xfce-base/libxfce4ui/{libxfce4ui-4.18.6.ebuild => libxfce4ui-4.18.6-r1.ebuild} (82%)
--
2.44.2
next reply other threads:[~2024-06-23 17:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-23 17:35 Eli Schwartz [this message]
2024-06-23 17:35 ` [gentoo-dev] [PATCH 1/5] gui-libs/gtk: add a "poison" macro support to disable X/wayland Eli Schwartz
2024-06-24 9:08 ` Florian Schmaus
2024-06-26 9:03 ` Sam James
2024-06-27 4:52 ` Eli Schwartz
2024-06-27 4:58 ` Sam James
2024-07-03 11:16 ` Mart Raudsepp
2024-07-03 17:26 ` Eli Schwartz
2024-06-23 17:35 ` [gentoo-dev] [PATCH 2/5] net-libs/gtk-vnc: prevent automagically building against gtk[X,wayland] Eli Schwartz
2024-06-23 17:35 ` [gentoo-dev] [PATCH 3/5] x11-libs/wxGTK: " Eli Schwartz
2024-06-23 17:35 ` [gentoo-dev] [PATCH 4/5] xfce-base/libxfce4ui: prevent automagically building against gtk[wayland] Eli Schwartz
2024-06-23 17:35 ` [gentoo-dev] [PATCH 5/5] dev-libs/libportal: prevent automagically building against gtk[X,wayland] Eli Schwartz
2024-06-23 18:33 ` [gentoo-dev] [PATCH 0/5] Fixing automagic dependencies on gtk[wayland,X], James Le Cuirot
2024-06-26 9:02 ` Sam James
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240623173646.3368935-1-eschwartz93@gmail.com \
--to=eschwartz93@gmail.com \
--cc=binhost@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=gnome@gentoo.org \
--cc=xfce@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox