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 |