TL;DR: Pacman gives up on version bounds checking if a package provides a package unversioned, warn against such behaviour to make pacman more robust. Consider the following common scenario. A package `D'` which is a variant of `D` is made (eg a VCS nightly package). The packager adds `provides=(D)` to `D'`'s `PKGBUILD` so that packages depending on `D` can work with `D'` instead. Now a package `P` needs some version guarantees on `D` -- maybe it's tightly coupled with particular versions of `D` and needs `D=$verD`[1], maybe it needs a bugfix in `D` only provided in a certain version[2] (in particular, a nightly `D'` in AUR might be ahead of `D` in the official repos and might provide that version). So `P` adds `depends=('D>=$verD`)`. Unfortunately, this combination does not work -- on a system with `D'` installed, attempting to install `P` will fail with `target not found: D>=$verD`. Pacman's blindness to the existing `D'` is confusing and hard to diagnose if one is unaware of this behaviour. (To be fair to pacman, this conservatism makes sense -- perhaps eg the upstream changed versioning schemes when it changed names) To make avoiding these kinds of situations easier, `namcap` should warn against unversioned `provides` in a `PKGBUILD`, ie bare `provides=(pkg)` lines with no versioning information. See also https://gitlab.archlinux.org/pacman/pacman/-/issues/225 This was also (mistakenly) reported at: https://gitlab.archlinux.org/archlinux/devtools/-/issues/265 [1]: https://aur.archlinux.org/packages/pandoc-crossref-static-git [2]: https://aur.archlinux.org/packages/python-habanero