Re: upstream advise page about circular dependencies (bootstrapping)

[Simon McVittie <smcv@debian.org>]

On 12/02/13 12:40, Johannes Schauer wrote:
> But besides those simple cycles there are other cycles of length 2 when
> taking whole installation sets into account. For example src:pkg-config
> indirectly build depends on pkg-config because src:pkg-config build
> depends on libglib2.0-dev which depends on pkg-config.

Either GLib or pkg-config should document how you can avoid this cycle
by doing a "stage 1" build of one project or the other. pkg-config used
to have an embedded subset of GLib which it could use instead of the
system copy to break this cycle, but I think the recommended way these
days is GLib without pkg-config, which you can do by turning the
information that pkg-config would have given you into configure
arguments, something like this:

    ./configure \
        PKG_CONFIG=false \
        ZLIB_CFLAGS=-I/usr/include ZLIB_LIBS="-L/usr/lib -lz" \
        LIBFFI_CFLAGS=-I/usr/include LIBFFI_LIBS="-L/usr/lib -lffi" \
        --disable-libelf \
        --with-pcre=internal

There is a tension here between the way we want to build high-quality
packages for the real distribution (no embedded code copies, no
duplication, full functionality, regression tests) and the ability to
build them without dependency cycles (which often implies reduced
functionality or testing, or an embedded code copy).

There's a good reason why the /DebianBootstrap effort is based on doing
"stage 1" builds with just enough functionality to break the cycle,
rather than on eliminating cycles altogether.

I think the advice to upstreams should be "keep it *possible* to build
your software without cycles (perhaps with degraded functionality), and
document how".

> libdbus-glib-1-dev -> src:dbus
> python-dbus -> src:dbus

Both are easily broken by building src:dbus with reduced test coverage
and reduced features, currently documented via comments in
debian/control. I plan to upload a version to experimental that supports
"stage1" builds, as soon as the current bootstrapping proposals solidify
far enough that that's possible.

I believe src:dbus <-> src:systemd is also a cycle, when running Linux.
Again, it should be broken by building src:dbus without systemd support,
building src:systemd, then rebuilding src:dbus with systemd support.

> src:python2.7 -> python

Entirely a matter of how Debian packages it; upstream Python is
self-contained.

> libglib2.0-dev -> src:pkg-config

See above.

Regards,
    S