search

pkgcore / pkgcheck

pkgcore-based QA utility for ebuild repos
https://pkgcore.github.io/pkgcheck
BSD 3-Clause "New" or "Revised" License
35 stars 29 forks source link

[New Check]: MULTILIB_USEDEP in BDEPEND #715

Open floppym opened 1 week ago

floppym commented 1 week ago

Is there an existing such new check request for this?

Explain

It is rarely valid to reference MULTILIB_USEDEP in BDEPEND.

MULTILIB_USEDEP contains a USE flag expression that is based on USE flags set for the current package being built. The USE flags will be based on CHOST, not CBUILD.

https://bugs.gentoo.org/723112 https://bugs.gentoo.org/944040

Examples

https://gitweb.gentoo.org/repo/gentoo.git/tree/app-crypt/mit-krb5/mit-krb5-1.21.3-r1.ebuild?id=de41a3ba38ba1ccb98bae20e443a1af8d8df5c6a#n39

Output message

No response

Documentation

No response

Result level

warning

floppym commented 1 week ago

Some edge cases were identified in #gentoo-qa:

rust.eclass utilizes MULTILIB_USEDEP in BDEPEND, possibly in a valid way.

wine also utilizes it, but could probably be changed to hard-code abi_x86 instead. It is probably abusing the abi_x86 USE flags anyway.

Should probably hold off on this request until the rust case can be thought through.

ionenwks commented 1 week ago

tl;dr not an important read, but just tossing my thoughts wrt wine here in case needed later

wine also utilizes it, but could probably be changed to hard-code abi_x86 instead. It is probably abusing the abi_x86 USE flags anyway.

Technically abi_x86_32 is indeed incorrect on wine's mingw64-toolchain given first it's more like abi_x86_pe32 (if that existed), it's not the same class of libraries, and then libraries are also installed in non-standard paths for private toolchain usage.

If USE was renamed, would instead end up with BDEPEND="abi_x86_32? ( mingw64-toolchain[32bitUSE] ) which doesn't change much for wine's specific case but it'd be more correct (Edit: could be visited if need be, esp. given it's currently weird to unmask abi_x86_32 on no-multilib for mingw64-toolchain and wine's newfound way to get 32bit support without ELF multilib)

More normally, wine itself depends on several abi_x86_32 ELF libraries and the multilib usage is fairly normal there, and that's why we use abi_x86_32 to also request mingw64-toolchain's support.

Either way, hardcoding as a quickfix would indeed not be a problem given we know exactly which are supported (has explicit MULTILIB_COMPAT) and the generated variable is not important. None of these packages are currently keyworded on anything but amd64+x86 too and have KEYWORDS="-* ..." on top. I'd be opposed to moving mingw64-toolchain to DEPEND though, that's even more incorrect as it'd never look at it in anything but BROOT.