On Tue, Jun 14, 2022 at 2:15 PM Mike Rochefort <mroche(a)redhat.com> wrote:
On Mon, Jun 13, 2022 at 4:18 PM Chris Adams <linux(a)cmadams.net> wrote:
>
> Once upon a time, Josh Boyer <jwboyer(a)redhat.com> said:
> > If the dependency is only needed at build time, which is what CRB
> > content is intended for
>
> If that's the intent, then it's not implemented correctly. For example,
> there are well over 100 perl modules in CRB 9. They may only be used
> _by Red Hat_ in building, but they are not exclusively build-time
> packages by a long shot.
If it helps, I've updated my CRB scanner and the results (hopefully
it's accurate) for seeing what EPEL packages depend on CRB packages
(via "dnf rq --whatdepends <crb_package>") for both EL8 and EL9. These
were run against RHEL 8 and 9 repositories with EPEL (so no EPEL
Next). I don't believe it'll catch everything (such as things in
epel-modular), but it could be a decent starting point for review.
Would also be useful to know if this methodology is flawed and
inaccurate.
https://gitlab.com/omenos/crb-depends
Not fully sure I understand the results, but this looks promising.
Thanks for providing it!
One thing I caught on initial glance, I think it's getting confused on
multilib. For example, from:
https://gitlab.com/omenos/crb-depends/-/blob/main/el9/FINAL_EPEL.json
"gvfs.i686": [
"lutris-0:0.5.10.1-1.el9.x86_64"
],
That seems to be highlighting that lutris.x86_64 depends on gvfs.i686.
I don't think that's actually the case, because gvfs.x86_64 is shipped
in AppStream and should satisfy the dependency for lutris.x86_64 in
EPEL.
josh