[Bug debuginfod/25509] Break a cyclic dependency by core packages

mark at klomp dot org sourceware-bugzilla@sourceware.org
Thu Jun 25 08:51:19 GMT 2020


--- Comment #17 from Mark Wielaard <mark at klomp dot org> ---
Just to be clear, the current setup is:

--enable-debuginfod or --enable-debuginfod=yes: builds all debuginfod
server/client artifacts (requires libcurl)
--disable-debuginfod or --enable-debuginfod=no: builds none of the debuginfod
server/client artifacts.

The proposed patch introduces:

--enable-libdebuginfod or --enable-libdebuginfod=yes: builds the debuginfod
client artifacts
--disable-libdebuginfod or --enable-libdebuginfod=no: don't build the
debuginfod client artifacts
--enable-libdebuginfod=dummy: builds all debuginfod clients artifacts, but the
libdebuginfod.so is just a stub (does not depend on libcurl).
--enable-debuginfod or --enable-debuginfod=yes: builds all debuginfod server
artifacts (requires either --enable-libdebuginfod=yes or
--enable-libdebuginfod=dummy and sqlite3, microhttpd, libarchive)
--disable-debuginfod or --enable-debuginfod=no: build none of the debuginfod
server artifacts.

I am hoping that helps both the Suse use case which would like a
bootstrap/dummy libdebuginfod.so (--enable-libdebuginfod=dummy
--disable-debuginfod) and the Arch use case which is to only have the client
library, but not the debuginfod server (--enable-libdebuginfod

I admit that having the combination --enable-libdebuginfod=dummy and
--enable-libdebuginfod is somewhat redundant/non-sensical, but it helps with
(build time) testing. Other testing matrix would imho be as complicated (you'll
get extra install flags or need to setup compile time or runtime environment

You are receiving this mail because:
You are on the CC list for the bug.

More information about the Elfutils-devel mailing list