From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C589215817D for ; Sun, 23 Jun 2024 17:36:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3210BE29FC; Sun, 23 Jun 2024 17:36:51 +0000 (UTC) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EFDACE29ED for ; Sun, 23 Jun 2024 17:36:50 +0000 (UTC) Received: by mail-oi1-x233.google.com with SMTP id 5614622812f47-3c9cc66c649so1785977b6e.1 for ; Sun, 23 Jun 2024 10:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719164209; x=1719769009; darn=lists.gentoo.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=es7bnpdUzy/bDPx3cGv9rY4KJtCR7xUfAeP4d3QUiek=; b=YEnIUxFGVXdDbtMc9Xz10BK/13MiI9eeZAuyqlaxxIolCKLzGt0mfpIb/psJxkHzbM 4flwjCZBo3xkCbg0C8/CROvvDQ920N0qqiCbMjGeZrWVa261CGfG67ZkaRmbdqnrT0Sh kfgzOUMaSOGNPLSA0Tb8nv0Nqc4T0am7nLssde5/bKqzBK2rKC34mlCOT0GDS61AFDkN HlRKRmvtTiDqL090uSMOxhUTEeC67HNv4DbGCr+WyzZQ/BH4ZZv/P+XrInPy7ja081kg J3GRlSRm3SwYVYJ9hV5KYXpKAjzsT97wGIzUNGnv2PjbV/4HaernXgQJAqikyVh5Sa/K 5HVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719164209; x=1719769009; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=es7bnpdUzy/bDPx3cGv9rY4KJtCR7xUfAeP4d3QUiek=; b=B8dJ6bD9UBOyqh0I0gdXRspUWgH9pB++L6P77RKLmWqpQGXhSLinOolFu08cPQKrpj MOJgTKsCC+YkPUB+D9U4vqhNCY9LCN+ngE8L0MWHPHuZwXE6WSefCYNstKai/r3g7Gun F/h7UuIKqe0EQtxQrvbpKqoywn7hz6fXB3Bm4qTte72EEyD+jMWxhTmC6m6xi0ryqnbI 0TCBlMlx0/N6gzk5lBwaqrWRICGqbmahiJKh8y24dA/8etyJJ5dH/fBc8DZwhZ0Xb8Zz X30AffXaAauqbeaoJYAt3PPuJUBTmZAW+wg7B4mA4X+levtI/8ksG3sH/9EjmQy+u2mL r+4w== X-Gm-Message-State: AOJu0YxuoeUjIzGqXg/aGPIuRi+SiJflkegsbts4pdbqhC8Z83vIytx0 D/YHMM0ovMhbR+KrTqQyNjdvpknF8I/pOp4Tv72ndGLAKYrcZT5WE9SH11J1 X-Google-Smtp-Source: AGHT+IFkzFUf0EDor6Vdso8gQ0dq0atxNER7hMgqEBcd9qlq0pqHAUuxuP79EPEZVIl/ZAzn8y6oTQ== X-Received: by 2002:a05:6808:318d:b0:3d2:2c03:863a with SMTP id 5614622812f47-3d545a8f91dmr3815963b6e.55.1719164209415; Sun, 23 Jun 2024 10:36:49 -0700 (PDT) Received: from acleverhostname.lan ([2603:6011:3f0:69d0::12ac]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-444c2c88de3sm33620671cf.87.2024.06.23.10.36.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Jun 2024 10:36:48 -0700 (PDT) From: Eli Schwartz 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 Message-ID: <20240623173646.3368935-1-eschwartz93@gmail.com> X-Mailer: git-send-email 2.44.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: a173a8bb-293d-4b82-a2ea-bd8b3108bf42 X-Archives-Hash: 2d3b0008224fc278714a375b71bd35d2 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