On Sun, Apr 28, 2019 at 4:57 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> 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. > I've worked in distributions that have implemented this policy, and it's often much more frustrating to work with because of it. It's not always obvious that pkgconfig missing is the reason why stuff doesn't build or otherwise work correctly. I'm pretty sure the reason for having the auto-generated requirement on pkg-config was to make it easy and obvious to use stuff through pkgconfig. I'm personally not in favor of doing this. I know that recently there has been this kick to shrink the default buildroot and minimize the dependency chain in extreme ways. I'm fairly certain a chunk of this has to do with RHEL modularity, but there's also the obvious bit of speeding up buildroot construction. But to be honest, this isn't a significant drain on the dep chain (if we still had the other pkgconfig implementation, it might be, since that pulled in glib2 in the minimal tree). If the problem is pkgconf-m4, I could be persuaded to drop pkgconf-pkg-config's requirement on it. I kept it there principally because the old pkgconfig package had the m4 file in there too. The impact is minimal, it's a developer-side dependency anyway, and it's often useful to have. So from my point of view, I don't see a problem with it. And the dependency generator already makes it "/usr/bin/pkg-config", so you could theoretically swap it with any other conforming implementation. In the end, I don't see any reasonable benefit for doing this, and it just makes developer and packaging work more frustrating. Also, w.r.t. so files, we _do_ pull in the linker library. The library "ld-linux-$ARCH.so.$SOMAJOR" is always pulled in by every rpm containing a library. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
