VirtualProvidersCheck: new check for providers issues

[arthurzam]

• check for virtual package defining DEPEND or BDEPEND
• check for virtual package with a single provider across versions
• All of them of Warning level

The logic for the single provider is:

1. Every version has one provider (compares full atom, for cases like when we depend on one of use flags)
2. Collecting all unversioned unslotted RDEPENDs gives us only one match --> to which we should replace the virtual.

Closes: https://bugs.gentoo.org/744784

results over gentoo repo

virtual/acl
  VirtualWithSingleProvider: virtual package with a single provider: sys-apps/acl

virtual/blas
  VirtualWithDepend: version 3.8: virtual package with a DEPEND defined

virtual/cblas
  VirtualWithDepend: version 3.8: virtual package with a DEPEND defined

virtual/imap-c-client
  VirtualWithSingleProvider: virtual package with a single provider: net-libs/c-client

virtual/jpeg
  VirtualWithSingleProvider: virtual package with a single provider: media-libs/libjpeg-turbo

virtual/lapacke
  VirtualWithDepend: version 3.8-r1: virtual package with a DEPEND defined

virtual/lapack
  VirtualWithDepend: version 3.8: virtual package with a DEPEND defined
  VirtualWithDepend: version 3.10: virtual package with a DEPEND defined

virtual/libiconv
  VirtualWithSingleProvider: virtual package with a single provider: dev-libs/libiconv

virtual/libintl
  VirtualWithSingleProvider: virtual package with a single provider: dev-libs/libintl

virtual/linuxtv-dvb-headers
  VirtualWithSingleProvider: virtual package with a single provider: sys-kernel/linux-headers

virtual/perl6
  VirtualWithSingleProvider: virtual package with a single provider: dev-lang/rakudo

virtual/pkgconfig
  VirtualWithSingleProvider: virtual package with a single provider: dev-util/pkgconf

virtual/ruby-ssl
  VirtualWithDepend: version 11: virtual package with a DEPEND defined
  VirtualWithBdepend: version 12: virtual package with a BDEPEND defined
  VirtualWithDepend: version 12: virtual package with a DEPEND defined

virtual/rubygems
  VirtualWithBdepend: version 16: virtual package with a BDEPEND defined
  VirtualWithDepend: version 16: virtual package with a DEPEND defined
  VirtualWithBdepend: version 17: virtual package with a BDEPEND defined
  VirtualWithDepend: version 17: virtual package with a DEPEND defined

virtual/tex-base
  VirtualWithSingleProvider: virtual package with a single provider: app-text/texlive-core

---

• Handle the case of virtual/libiconv and virtual/libintl

[codecov]

Codecov Report

Base: 81.11% // Head: 81.05% // Decreases project coverage by -0.06% ⚠️

Coverage data is based on head (9fefb10) compared to base (f3d6180).
Patch coverage: 66.66% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #484      +/-   ##
==========================================
- Coverage   81.11%   81.05%   -0.07%     
==========================================
  Files          55       55              
  Lines        8063     8095      +32     
  Branches     1810     1820      +10     
==========================================
+ Hits         6540     6561      +21     
- Misses       1425     1435      +10     
- Partials       98       99       +1     

Impacted Files	Coverage Δ
src/pkgcheck/checks/metadata.py	90.13% <66.66%> (-0.88%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[thesamesam]

• check for virtual package defining DEPEND or RDEPEND

You mean BDEPEND or DEPEND? ("not RDEPEND")?

[thesamesam]

These are false positives in an interesting way:

virtual/libiconv
  VirtualWithSingleProvider: virtual package with a single provider: dev-libs/libiconv

virtual/libintl
  VirtualWithSingleProvider: virtual package with a single provider: dev-libs/libintl

In libintl:

# - Don't put elibc_glibc? ( sys-libs/glibc ) to avoid circular deps between that and gcc.
RDEPEND="!elibc_glibc? ( !elibc_musl? ( dev-libs/libintl[${MULTILIB_USEDEP}] ) )"

The reason is that non-glibc & non-musl usually need an external libintl. In fact, musl needed it for a long time. This lets ebuilds be correct when they need libintl.

A real example of this is macOS, btw. Same for libiconv.

I'm not sure yet how to cleanly identify these. Maybe if the RDEPEND is "complex" (USE-conditionals) for VirtualWithSingleProvider, we should skip?

[arthurzam]

I'm not sure yet how to cleanly identify these. Maybe if the RDEPEND is "complex" (USE-conditionals) for VirtualWithSingleProvider, we should skip?

Added exception check for dependence on use flags starting with elibc_ and kernel_.

[thesamesam]

Sorry, I just wanted to check one thing (for other USE_EXPANDs), and we're all good.