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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A8F2C138334 for ; Wed, 18 Dec 2019 23:58:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A8EABE094F; Wed, 18 Dec 2019 23:58:27 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1B277E0901 for ; Wed, 18 Dec 2019 23:58:27 +0000 (UTC) Received: from sf (tunnel547699-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:3e6::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: slyfox) by smtp.gentoo.org (Postfix) with ESMTPSA id A05B634D9F2; Wed, 18 Dec 2019 23:58:25 +0000 (UTC) Date: Wed, 18 Dec 2019 23:58:22 +0000 From: Sergei Trofimovich To: Sebastian Pipping Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake Message-ID: <20191218235822.5b036cf2@sf> In-Reply-To: <85c9df6f-fcf5-61d7-90af-a375f5c75088@gentoo.org> References: <1a722f8f-36b5-c313-b6e1-eac75e0839c5@gentoo.org> <85c9df6f-fcf5-61d7-90af-a375f5c75088@gentoo.org> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) 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-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 17150d11-69fd-4159-8c17-820876d1ca81 X-Archives-Hash: 76645b5cc4f131ca1c9981d803ff936f On Wed, 18 Dec 2019 22:02:47 +0100 Sebastian Pipping wrote: > Hi all, >=20 >=20 > I noticed that dev-util/cmake depends on dev-libs/expat and that > libexpat upstream (where I'm involved) is in the process of > dropping GNU Autotools altogether in favor of CMake in the near future, > potentially the next release (without any known target release date). >=20 > CMake bundles a (previously outdated and vulnerable) copy of expat so > I'm not sure if re-activating that bundle =E2=80=94 say with a new use fl= ag > "system-expat" =E2=80=94 would be a good thing to resort to for breaking = the > cycle, with regard to security in particular. >=20 > Do you have any ideas how to avoid a bad circular dependency issue for > our users in the future? Are you aware of similar problems and > solutions from the past? Fun fact: cmake is not keyworded for riscv. To think of solutions enumerating the arising problems explicitly might help here. I see a few: 1. initial system bootstrap requires solving a circular dependency 2. recovery from broken state (expat soname bump without preserved libs or cmake broken by one of many depends it has) [2.] effectively forbids a dependency circle. [1.] is hard to solve without users' intervention to at least flip a defaul= t flag. Some other distributions provide two packages to break the cycle. Example Gentoo solution would be: "cmake.ebuild" depends on "expat.ebuild", "expat.ebuild" depends on "cmake-with-bundled-expat.ebuild". Some examples of circular dependencies are: a) gcc/glibc/binutils toolchain. the solution is to provide prebuilt binaries as part of stage3. b) self-hosted languages without an interpreter in C (rust, golang, ghc). The solution is to provide prebuilt binaries in ebuilds. c) circular dependencies in tests. The solution is careful user's USE flags juggling: enable USE=3Dtest only for a package being tested. d) glibc depends on libidn2 to implement modern DNS demangling. glibc fixes it by not depending on libidn at build time and does manual library loading with dlopen()/dlsym(). e) vast majority of others: dependency bundling (users of autotools, gnulib= , zlib, lua). All the above are not pretty. a) is simplest to maintain by ebuild maintain= er and gentoo user, but probably not by releng. c) moves the burden to user. I personally would explore [e]: unconditional bundling of expat into cmake and make sure it's kept up-to-date there. [c] would be nice to be solved at portage level if portage could schedule multiple merges for the same package with different USE flags. --=20 Sergei