Simon McVittie writes:
> For some libraries, the only maintainer-supported way to consume the
> library is via pkg-config. If that's the case, then a dependency on
> pkg-config can be appropriate - although we don't add a dependency on
> cc or binutils, which is equally necessary.
Well, cc and
On Thu, 09 Dec 2021 at 15:24:27 +0100, Alexander Traud wrote:
> if the header included another header,
> and that header included further headers but was not in the root but in
> a subfolder, an -I flag *might* be required. For example, the package
> 'libopusfile-dev' has its header file in
On Fri, 17 Dec 2021 at 10:05:39 +0100, Alexander Traud wrote:
> I do not understand why:
> a) pkg-config itself is *not* a dependency as well
Sometimes it is appropriate for it to be, and sometimes it is not.
For some libraries, the only maintainer-supported way to consume the
library is via
The problem of "Requires.private", for C/C++ libraries, it (might)
contain two different things: Libraries used for static linking *and*
Cflags to preprocess the header files.
If the position of Debian is that each reference in "Requires.private"
translates into a required dependency in
Simon McVittie writes:
> If you're linking statically, you need to be able to satisfy the
> recursive dependencies of libunbound (regardless of whether you are
> using pkg-config or not), so, no, you will need nettle-dev and
> libevent-dev either way.
And, specifically, I think we should say as
On Mon, 13 Dec 2021 at 22:46:43 +0100, Alexander Traud wrote:
> Let us assume 'bar.pc' would create a dependency in Debian, then the
> question arises: Why does the Debian maintainer not transform it to
> 'Libs.private', not upstream but via a Debian patch? That would avoid
> such
> If foo.pc in libfoo-dev references bar.pc [...]
That is the problem: If 'bar.pc' is referenced just because for static
libraries, why does it create a dependency for me as a user, who is
a) not using pkg-config at all
and/or
b) linking dynamically?
Let us assume 'bar.pc' creates a
This is all pretty straightforward. If foo.pc in libfoo-dev references
bar.pc that lives in libbar-dev, then libfoo-dev needs a dependency on
libbar-dev, and the missing dependency is a serious bug. That has been
the case for as long as I remember, and doesn't require more long
discussions or
Linux distributions, which have separate packages for developers, like
Debian, are not really supported [1] by the developer tool pkg-config
[2]. The problems are C/C++ libraries which depend on other libraries at
runtime. Let us pick one, a security library for utilizing DNSSEC:
$ sudo apt
9 matches
Mail list logo
