[cancelled] Re: dropping autogenerated dependency on pkg-config

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