Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

[Sergei Trofimovich]

On Wed, 18 Dec 2019 22:02:47 +0100
Sebastian Pipping <sping@g.o> 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?

Fun fact: cmake is not keyworded for riscv.

To think of solutions enumerating the arising problems explicitly might
help here. I see a few:
1. initial system bootstrap requires solving a circular dependency
2. recovery from broken state (expat soname bump without preserved
  libs or cmake broken by one of many depends it has)

[2.] effectively forbids a dependency circle.

[1.] is hard to solve without users' intervention to at least flip a default flag.

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".

Some examples of circular dependencies are:
a) gcc/glibc/binutils toolchain. the solution is to provide prebuilt
  binaries as part of stage3.
b) self-hosted languages without an interpreter in C (rust, golang, ghc).
  The solution is to provide prebuilt binaries in ebuilds.
c) circular dependencies in tests. The solution is careful user's USE flags
  juggling: enable USE=test only for a package being tested.
d) glibc depends on libidn2 to implement modern DNS demangling.
    glibc fixes it by not depending on libidn at build time and does manual
    library loading with dlopen()/dlsym().
e) vast majority of others: dependency bundling (users of autotools, gnulib, zlib, lua).

All the above are not pretty. a) is simplest to maintain by ebuild maintainer
and gentoo user, but probably not by releng. c) moves the burden to user.

I personally would explore [e]: unconditional bundling of expat into
cmake and make sure it's kept up-to-date there.

[c] would be nice to be solved at portage level if portage could schedule
multiple merges for the same package with different USE flags.

-- 

  Sergei