On Sun, Apr 28, 2019 at 11:34 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
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.
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@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
_______________________________________________ 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
