public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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



             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