Bug 942601 – sys-apps/portage-3.0.65-r1: 'emerge -k' and 'emerge -K' package-handling differs

• Product: Portage Development
• Status: UNCONFIRMED ---

[Description Stuart Shelton 2024-10-31 13:26:26 UTC]

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.

[Comment 1 Stuart Shelton 2024-11-09 12:55:38 UTC]

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.

[Comment 2 Stuart Shelton 2024-12-02 15:27:18 UTC]

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.

[Comment 3 Sam James 2024-12-02 15:30:23 UTC]

(In reply to Stuart Shelton from comment #2)

I think that may warrant its own bug.