This is the mail archive of the
mailing list for the elfutils project.
[Bug debuginfod/25509] Break a cyclic dependency by core packages
- From: "marxin.liska at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: elfutils-devel at sourceware dot org
- Date: Thu, 06 Feb 2020 13:34:06 +0000
- Subject: [Bug debuginfod/25509] Break a cyclic dependency by core packages
- Auto-submitted: auto-generated
- References: <email@example.com/bugzilla/>
--- Comment #4 from Martin Liška <marxin.liska at gmail dot com> ---
(In reply to Mark Wielaard from comment #2)
> (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?
You can find the 2 spec files here:
> > So the question is how to unbreak all these dependencies for future core
> > packages?
> 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.