[Bug]: Missing detection for invalid built-slot-operator dep spec

[thesamesam]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Portage will refuse packages with DEPEND containing := with a fixed subslot, e.g. Blender's dev-util/hip:0/5.7=).

media-gfx/blender-4.1.1-r1::gentoo (masked by: invalid: DEPEND: Improper context for slot-operator "built" atom syntax: dev-util/hip:0/5.7=, invalid: RDEPEND: Improper context for slot-operator "built" atom syntax: dev-util/hip:0/5.7=)

It isn't legal to specify app-misc/foo:0/x= because 0/x is the subslot, it doesn't make sense to say it can then rebuilt for a source package. This syntax is legal in Portage's vdb because it records what was actually built against.

PMS (8.3.3) says:

To implement the equals slot operator, the package manager will need to store the slot/sub-slot pair of the best installed version of the matching package.
This syntax is only for package manager use and must not be used by ebuilds. The package manager may do this by inserting the appropriate slot/sub-slot pair between the colon and equals sign when saving the package’s dependencies.
The sub-slot part must not be omitted here (when the SLOT variable omits the sub-slot part, the package is considered to have an implicit sub-slot which is equal to the regular slot).

I fixed this in ::gentoo in 875e4444e2fcdf7b7d6d70f05f9ff26635aa144f. The bad ebuild is at https://github.com/gentoo/gentoo/blob/875e4444e2fcdf7b7d6d70f05f9ff26635aa144f~1/media-gfx/blender/blender-9999.ebuild#L90.

Expected Behavior

pkgcheck should raise an invalid dependency result.

pkgcheck version

pkgcheck 0.10.31-3-g48fbc35 -- Thu, 4 Jul 2024 23:07:15 +0300

pkgcore version

pkgcore 0.12.28-3-gaa9418b -- Thu, 4 Jul 2024 22:32:44 +0300

[radhermit]

I'd recommend only adding this detection to pkgcheck and not try to conditionally error out in the underlying dep parser in pkgcore as doing that properly would require threading a conditional down to relevant functions, complicating the process.

For reference, I noticed the same oversight in pkgcraft so the case is now flagged via pkgcruft: pkgcraft/pkgcraft@e721dbc5c.