The behaviour of 'emerge -k …' and 'emerge -K …' unexpectedly differs, with the 'emerge -K' behaviour being incorrect IMHO: If a binhost is active and contains several builds of the same version of a given package with different USE flags then - * 'emerge -k' will select the package with the same flags as those currently set on the host where the command was issued; * 'emerge -K' will select the most recently built package, even if the USE flags are different and another package exists with matching USE flags. This means that 'emerge -K' is ignoring environment and file USE flags and so is often not usable.
Another instance: ``` / # emerge -Kva net-dns/bind --with-bdeps=y These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 14.67 s (backtrack: 1/100). !!! All ebuilds that could satisfy "sys-libs/glibc:2.2" have been masked. !!! One of the following masked packages is required to complete your request: - sys-libs/glibc-2.39-r6 (masked by: use flag configuration mismatch) (dependency required by "@__auto_slot_operator_replace_installed__" [argument]) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. / # emerge -kva net-dns/bind --with-bdeps=y These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 72.45 s (backtrack: 0/100). … Total: 68 packages (68 new, 68 binaries), Size of downloads: 0 KiB Would you like to merge these packages? [Yes/No] ``` … so with '-K' dependency resolution fails, whilst with '-k' everything resolves from binary packages and the apparent `glibc` dependency which is breaking initially isn't even pulled-in.
Additionally, the (now deprecated presumably, given that it's only documented as applying to EAPI 6 and below?) `--root-deps` option causes portage to disregard any packages already installed in ROOT='/' when root is set to some other value - meaning that the app-arch/xz-utils -> app-portage/elt-patches -> app-arch/xz-utils circular dependency is hit if any package doesn't have a binary pre-built. This is admittedly easily remedied by removing "--root-deps", but it's another gotcha with the current portage dependency-resolution implementation.
(In reply to Stuart Shelton from comment #2) I think that may warrant its own bug.
