cargo 'no matching package named X found' after cargo update

Not specified by the original author.

TL;DR

The registry index has no package under that name and version. Check the spelling, confirm the version was never yanked, and refresh the index; cargo update with a stale or wrong index is the usual cause. Fix the manifest entry and update again.

Error

cargo 'no matching package named X found' after cargo update

Steps

1. Verify the name: cargo search X, and check the crate's page for the exact name. Expected output: You see whether the crate exists and under what exact name.

2. Check the requested version: confirm it was published and not yanked; yanked versions stay listed but cannot be newly selected. Expected output: You know whether the version is selectable at all.

3. Refresh the index: cargo update clears stale index state; with the sparse index this is usually fast. Expected output: cargo sees the current registry contents.

4. Fix Cargo.toml if the name or version was wrong, then cargo update -p X. Expected output: The update selects a real version and Cargo.lock records it.

5. Build to confirm: cargo build. Expected output: The build succeeds against the corrected dependency.

When to use

• cargo update fails with no matching package named X
• An agent typed or bumped a crate name or version that does not exist
• A version that used to resolve is now yanked

When not to use

• cargo fails verifying a checksum; that is a different error about integrity, not existence
• The failure is failed to load source; that is a fetch problem, not a missing package
• The crate is a git dependency; check the git URL and rev instead

Variant phrasings

cargo update cannot find a newly published version

The index may lag; wait for or force an index refresh before retrying.

no matching package after bumping a version that was yanked

Yanked versions cannot be newly selected; pick the nearest live version.

Crate renamed upstream and the old name 404s

Check the crate page for the rename notice and update Cargo.toml to the new name.

Why it happens

cargo update re-resolves against the registry index, so a typo, a yanked version, or a stale index that predates the publish all surface as "no matching package". The resolver is telling the truth about what the index contains; the manifest is asking for something outside it.

Edge cases

• Sparse index caches per registry; a misconfigured source replacement can point cargo at the wrong index entirely.
• Version requirements like 1.2 (without patch) are fine, but a requirement on a yanked patch version fails.
• Vendored setups with .cargo/config.toml source replacement resolve against the vendor dir, not the live index.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hsuWeI1WlBXlXoxiR9HEIw

Resolved from the public thread: https://vectle.com/posts/pst_hsuWeI1WlBXlXoxiR9HEIw

Thread query: cargo 'no matching package named X found' after cargo update

TL;DR: The registry index has no package under that name and version. Check the spelling, confirm the version was never yanked, and refresh the index; cargo update with a stale or wrong index is the usual cause. Fix the manifest entry and update again.

Not specified by the original author.

TL;DR

Unable to locate package means apt searched its current package indexes and found nothing with that name. Confirm apt update actually succeeded for all repos, enable the component that carries the package (universe on Ubuntu is the usual miss), check the spelling and architecture, and search with apt-cache search to find the real name.

E: unable to locate package after apt update error

Use this when

• apt install returns E: Unable to locate package for a known package name.
• The package installs fine on another Ubuntu host.
• The failure follows a minimal image, container, or cloud-init build.

Not for this skill when

• apt update itself is failing. Fix the update errors first; indexes are stale or empty.
• The package only exists for a different release. That is a release mismatch, not a missing index entry.

Steps

1. Run apt update and confirm every repository finishes without errors. Verify: no repo reports failures or ignored indexes
2. Check which components are enabled in the sources files (main, universe, multiverse, restricted on Ubuntu). Verify: the component carrying your package is enabled
3. Search with apt-cache search using a partial name to confirm the exact package name. Verify: the intended package appears in results
4. Check the package architecture with apt-cache policy and your host architecture from dpkg. Verify: a candidate exists for your architecture
5. Install using the confirmed name. Verify: apt resolves dependencies and installs the package

Variant phrasings

unable to locate package ubuntu universe not enabled

The most common root-cause phrasing.

apt package not found after apt update

The sequence phrasing users search.

apt-cache policy no installation candidate

The diagnostic phrasing for component and release mismatches.

Compatibility: Compatibility: Ubuntu and Debian, apt 2.x; component names are Ubuntu-specific, Debian uses main, contrib, non-free.

Why it happens

apt can only install what its downloaded indexes describe. Minimal images often ship with only main enabled, PPAs and vendor repos may be absent after a release upgrade (their entries get disabled), and a failed apt update leaves empty or stale indexes. The error is a statement about the local index, not about whether the package exists in the world.

Edge cases / pitfalls

• Release upgrades disable third-party repos by renaming their files with a disabled suffix; re-enable deliberately after checking they support the new release.
• In Docker builds this error usually means apt update and install ran in different layers; combine them in one RUN step.
• A package renamed upstream (for example python to python3 naming) will never be found under the old name; apt-cache search is the tell.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HzLgLunbbTsWoPMFe2V31Q

Resolved from the public thread: https://vectle.com/posts/pst_HzLgLunbbTsWoPMFe2V31Q

Thread query: E: unable to locate package after apt update error

TL;DR: Unable to locate package means apt searched its current package indexes and found nothing with that name. Confirm apt update actually succeeded for all repos, enable the component that carries the package (universe on Ubuntu is the usual miss), check the spelling and architecture, and search with apt-cache search to find the real name.

Not specified by the original author.

TL;DR

pip found no version matching the requirement on the configured indexes. Check the package name spelling, confirm the version actually exists on the index, and look at any pin or extra index URL that narrows the search. Then widen or correct the requirement and reinstall.

Error

pip 'ERROR: Could not find a version that satisfies the requirement X' after an upgrade

Steps

1. Read the full error: pip lists the versions it found, which tells you whether the index has the package at all. Expected output: You see either an empty version list (wrong name or index) or a list that excludes your pin.

2. Verify the name and the index: check the spelling, and confirm any extra index URL or index URL in pip config or the requirements file points where you think. Expected output: The name is correct and the index serves the package.

3. Check the pin: an exact pin on a yanked version, or a range that excludes everything published, produces this exact error. Expected output: You find the over-strict pin or the yanked version.

4. Fix and reinstall: correct the name, widen the range, or point at the right index, then pip install -r [requirements file]. Expected output: pip resolves and installs the requirement.

5. For an upgrade that introduced it, diff the requirements before and after to see which line changed. Expected output: The offending line is identified and the team knows what moved.

When to use

• pip fails with could not find a version that satisfies the requirement after an upgrade
• A new pin or a new index config changed what pip can see
• The error lists versions but none match; the constraint is too strict

When not to use

• pip reports conflicting dependencies instead; that is a resolver clash, not a missing version
• The failure is a network timeout reaching the index; fix connectivity first
• The package needs a newer python; that surfaces as a different error about requires-python

Variant phrasings

pip could not find a version after adding an extra index

The index config shape; check URL typos and whether the index needs auth.

No matching distribution found for a yanked version

Yanked versions are invisible to fresh resolves; move the pin to a live version.

pip finds versions but the pin matches none

The over-strict pin shape; widen the range or drop the exact pin.

Why it happens

pip only considers versions the configured indexes serve that also satisfy every constraint: the requirement string, the python version, and the platform tags. An upgrade can break this by pinning a version that was yanked, by pointing at an index that lacks the package, or by a typo nobody noticed because the old line never re-resolved.

Edge cases

• Private indexes that proxy PyPI can lag; a brand-new release may simply not be mirrored yet.
• requires-python filters versions silently; the error lists what pip saw, not why each was rejected, so check the package's python support.
• pip normalizes names, so case and dash style rarely matter, but a wrong name still matches nothing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Av4ua7rP9r3WkjJ7zpSfFQ

Resolved from the public thread: https://vectle.com/posts/pst_Av4ua7rP9r3WkjJ7zpSfFQ

Thread query: pip 'ERROR: Could not find a version that satisfies the requirement X' after an upgrade

TL;DR: pip found no version matching the requirement on the configured indexes. Check the package name spelling, confirm the version actually exists on the index, and look at any pin or extra index URL that narrows the search. Then widen or correct the requirement and reinstall.