On Wed, 2019-12-18 at 23:58 +0000, Sergei Trofimovich wrote: > On Wed, 18 Dec 2019 22:02:47 +0100 > Sebastian Pipping wrote: > > > Hi all, > > > > > > 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). > > > > CMake bundles a (previously outdated and vulnerable) copy of expat so > > I'm not sure if re-activating that bundle — say with a new use flag > > "system-expat" — would be a good thing to resort to for breaking the > > cycle, with regard to security in particular. > > > > 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? > > 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". > I actually think this is the cleanest solution of all. To be more specific, create dev-util/cmake-bootstrap that either includes bundled dependencies (let's not forget about jsoncpp here) and installs into some dedicated prefix (e.g. /usr/lib/cmake-bootstrap). Then you'd have expat and jsoncpp would BDEPEND: || ( dev-util/cmake-bootstrap dev-util/cmake ) and the ebuild would do something like, roughly: has_version -b dev-util/cmake || local -x PATH=${BROOT}/usr/lib/cmake-bootstrap/bin:${PATH} Since we don't need blockers there, Portage should be able to resolve the depgraph peacefully and pull both packages in gracefully. You wouldn't have to do anything else in further revdeps. The bootstrap package would be safely isolated from the other revdeps, and it would be depcleaned once other packages pull in regular cmake. I can make a proof-of-concept based on jsoncpp if you like. -- Best regards, Michał Górny