[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


https://sourceware.org/bugzilla/show_bug.cgi?id=25509

--- 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
--disable-debuginfod).

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
variables).

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


More information about the Elfutils-devel mailing list