This is the mail archive of the
mailing list for the elfutils project.
[Bug debuginfod/25509] Break a cyclic dependency by core packages
- From: "mark at klomp dot org" <sourceware-bugzilla at sourceware dot org>
- To: elfutils-devel at sourceware dot org
- Date: Thu, 06 Feb 2020 11:35:47 +0000
- Subject: [Bug debuginfod/25509] Break a cyclic dependency by core packages
- Auto-submitted: auto-generated
- References: <firstname.lastname@example.org/bugzilla/>
Mark Wielaard <mark at klomp dot org> changed:
What |Removed |Added
CC| |mark at klomp dot org
--- Comment #2 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Martin Liška from comment #0)
> In openSUSE, we do face a problem with cyclic dependencies. Many core
> packages like gcc, glibc, elfutils or binutils depend on each other and
> create a cycle. The cycle should contain a reasonable amount of packages.
> When debuginfod was added to elfutils, we would have a huge bunch of
> dependencies caused by libhttpmicro and libsqlite. These have very many
> transitive dependencies.
debuginfod the tool has dependencies on libhttpmicro, libsqlite, libdw and
debuginfod-client depends on libcurl (which pulls in a lot of the crypto stuff
for https support).
libdw depends on debuginfod-client, but only indirectly through ldopen.
It does make sense to put these in different (output/sub) packages.
Which is actually what the sample elfutils.spec file in config/ does.
That doesn't "split" the inputs/dependencies of the source build though. Which
is what you seem most concerned with.
> So that I was forced to split elfutils into 2
> packages: elfutils and elfutils-debuginfod. The later contains all the new
> packages and is not part of the boostrap cycle.
> What's more problematic is that there are (and will be) tools that want to
> utilize libdebuginfod such as Binutils. As mentioned, the tool is in the
> bootstrap cycle and so that can't depend on elfutils-debuginfod.
Do you have a pointer to the spec files you are using now?
> So the question is how to unbreak all these dependencies for future core
The GNU Guix people also had some concerns about all the new dependencies and
also suggested splitting the package:
You are receiving this mail because:
You are on the CC list for the bug.