Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o, Sebastian Pipping <sping@g.o>
Subject: Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
Date: Thu, 19 Dec 2019 08:31:46
Message-Id: b5be4d4b2df2c96028451688b07cc21489ddf278.camel@gentoo.org
In Reply to: Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake by Sergei Trofimovich
1 On Wed, 2019-12-18 at 23:58 +0000, Sergei Trofimovich wrote:
2 > On Wed, 18 Dec 2019 22:02:47 +0100
3 > Sebastian Pipping <sping@g.o> wrote:
4 >
5 > > Hi all,
6 > >
7 > >
8 > > I noticed that dev-util/cmake depends on dev-libs/expat and that
9 > > libexpat upstream (where I'm involved) is in the process of
10 > > dropping GNU Autotools altogether in favor of CMake in the near future,
11 > > potentially the next release (without any known target release date).
12 > >
13 > > CMake bundles a (previously outdated and vulnerable) copy of expat so
14 > > I'm not sure if re-activating that bundle — say with a new use flag
15 > > "system-expat" — would be a good thing to resort to for breaking the
16 > > cycle, with regard to security in particular.
17 > >
18 > > Do you have any ideas how to avoid a bad circular dependency issue for
19 > > our users in the future? Are you aware of similar problems and
20 > > solutions from the past?
21 >
22 > Some other distributions provide two packages to break the cycle.
23 > Example Gentoo solution would be: "cmake.ebuild" depends on "expat.ebuild",
24 > "expat.ebuild" depends on "cmake-with-bundled-expat.ebuild".
25 >
26
27 I actually think this is the cleanest solution of all. To be more
28 specific, create dev-util/cmake-bootstrap that either includes bundled
29 dependencies (let's not forget about jsoncpp here) and installs into
30 some dedicated prefix (e.g. /usr/lib/cmake-bootstrap).
31
32 Then you'd have expat and jsoncpp would BDEPEND:
33
34 || ( dev-util/cmake-bootstrap dev-util/cmake )
35
36 and the ebuild would do something like, roughly:
37
38 has_version -b dev-util/cmake ||
39 local -x PATH=${BROOT}/usr/lib/cmake-bootstrap/bin:${PATH}
40
41 Since we don't need blockers there, Portage should be able to resolve
42 the depgraph peacefully and pull both packages in gracefully. You
43 wouldn't have to do anything else in further revdeps. The bootstrap
44 package would be safely isolated from the other revdeps, and it would be
45 depcleaned once other packages pull in regular cmake.
46
47 I can make a proof-of-concept based on jsoncpp if you like.
48
49 --
50 Best regards,
51 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies