Gentoo Archives: gentoo-dev

From: Sergei Trofimovich <slyfox@g.o>
To: Sebastian Pipping <sping@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
Date: Wed, 18 Dec 2019 23:58:32
Message-Id: 20191218235822.5b036cf2@sf
In Reply to: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake by Sebastian Pipping
1 On Wed, 18 Dec 2019 22:02:47 +0100
2 Sebastian Pipping <sping@g.o> wrote:
4 > Hi all,
5 >
6 >
7 > I noticed that dev-util/cmake depends on dev-libs/expat and that
8 > libexpat upstream (where I'm involved) is in the process of
9 > dropping GNU Autotools altogether in favor of CMake in the near future,
10 > potentially the next release (without any known target release date).
11 >
12 > CMake bundles a (previously outdated and vulnerable) copy of expat so
13 > I'm not sure if re-activating that bundle — say with a new use flag
14 > "system-expat" — would be a good thing to resort to for breaking the
15 > cycle, with regard to security in particular.
16 >
17 > Do you have any ideas how to avoid a bad circular dependency issue for
18 > our users in the future? Are you aware of similar problems and
19 > solutions from the past?
21 Fun fact: cmake is not keyworded for riscv.
23 To think of solutions enumerating the arising problems explicitly might
24 help here. I see a few:
25 1. initial system bootstrap requires solving a circular dependency
26 2. recovery from broken state (expat soname bump without preserved
27 libs or cmake broken by one of many depends it has)
29 [2.] effectively forbids a dependency circle.
31 [1.] is hard to solve without users' intervention to at least flip a default flag.
33 Some other distributions provide two packages to break the cycle.
34 Example Gentoo solution would be: "cmake.ebuild" depends on "expat.ebuild",
35 "expat.ebuild" depends on "cmake-with-bundled-expat.ebuild".
37 Some examples of circular dependencies are:
38 a) gcc/glibc/binutils toolchain. the solution is to provide prebuilt
39 binaries as part of stage3.
40 b) self-hosted languages without an interpreter in C (rust, golang, ghc).
41 The solution is to provide prebuilt binaries in ebuilds.
42 c) circular dependencies in tests. The solution is careful user's USE flags
43 juggling: enable USE=test only for a package being tested.
44 d) glibc depends on libidn2 to implement modern DNS demangling.
45 glibc fixes it by not depending on libidn at build time and does manual
46 library loading with dlopen()/dlsym().
47 e) vast majority of others: dependency bundling (users of autotools, gnulib, zlib, lua).
49 All the above are not pretty. a) is simplest to maintain by ebuild maintainer
50 and gentoo user, but probably not by releng. c) moves the burden to user.
52 I personally would explore [e]: unconditional bundling of expat into
53 cmake and make sure it's kept up-to-date there.
55 [c] would be nice to be solved at portage level if portage could schedule
56 multiple merges for the same package with different USE flags.
58 --
60 Sergei