On Sun, Apr 28, 2019 at 11:34 PM Neal Gompa <ngomp...@gmail.com> wrote:
> On Sun, Apr 28, 2019 at 4:57 PM Zbigniew Jędrzejewski-Szmek > <zbys...@in.waw.pl> 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. > I hope you are not talking about my Change Proposal because it has nothing to do with Modularity and/or RHEL :) 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. > I think I would start first dropping make from buildroot. > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
