On Wed, 2019-12-18 at 23:58 +0000, Sergei Trofimovich wrote:
> On Wed, 18 Dec 2019 22:02:47 +0100
> Sebastian Pipping <sp...@gentoo.org> 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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to