City automation CI reports that package A needs libX>=2 while package B pins libX<2, and the resolver aborts before tests run. What failed?
Select an answer to reveal the explanation.
Short Explanation
Two recipes that demand opposite spice jars cannot share one pantry—the resolver is telling you the declared parts collide. Adding a random extra jar does not fix version skew.
Full Explanation
When package A needs libX>=2 while package B pins libX<2 and the resolver aborts before tests run, the failure is incompatible component versions that cannot sit together in one resolved environment. The civic CI never reaches a coherent site-packages tree; the collision is among declared constraints, not among runtime assertions or cluster objects. Recognizing version incompatibility as its own failure class is the diagnostic skill.
A single missing package name with no version conflict would show “could not find” for one requirement, not opposing lower/upper bounds on the same library. A red assertion in test_health.py after a clean install implies the environment resolved successfully and tests executed—here the resolver aborts first. A Kubernetes readiness probe that never saw a listener on 8080 is a deploy-time health-contract issue and cannot explain a pre-test resolve abort.
Exam caveat: missing package and incompatible versions are related but distinct—absence versus mutually exclusive pins—and the exam expects you to pick the class that matches the opposing constraints. Operational check: list both packages’ constraints on libX, decide whether to relax a pin, upgrade/downgrade a consumer, or split environments, then re-run the resolve until install completes before enabling tests.