Due to lack of popular support for the idea (to put it mildly), I
won't be doing this.
Thank you all for participating in the discussion and good arguments
(both pro and con).
Zbyszek
On Sun, Apr 28, 2019 at 08:55:56PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> Hi everyone,
>
> currently, we autogenerate a dependency on pkg-config for all rpms
> that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config"
> returns 4632 entries on my laptop.
>
> This has always felt backward to me: those packages *provide* something
> that is used by pkg-config, they don't *require* pkg-config for anything.
> As an analogy, packages with headers are read by a C compiler, but
> we don't make them require gcc, and if a package ships an .so file, we
> don't add a dependency on the linker to it. Instead, anything which wants
> to consume .pc files should simply depend on the tools that consume those
> files (pkg-config, pkgconf, or a custom re-implementation).
>
> Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config
> (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
>
> Note: autogenerated Provides/Requires like pkgconfig(foo) are not
> part of this proposal.
>
> Advantages:
> - less entries in the dependency graph
> - removal of illogical dependency
> - less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, libpkgconf)
> (Those packages are small, maybe 200k together so this isn't a strong
> reason.)
>
> Disadvantages:
> - stuff that uses pkg-config or pkgconf will need to grow a dependency
> (e.g. meson which invokes /usr/bin/pkg-config internally).
> so there will be some churn.
>
> Zbyszek