[Bug] vip install never converges on Ubuntu 24.04: t64-renamed packages install but are never detected

[ian-flores]

On Ubuntu 24.04, vip install asks for four system packages, the suggested apt install succeeds, and re-running vip install asks for the same four packages again. There is no way out of the loop through the documented path. The packages are libatk1.0-0, libatk-bridge2.0-0, libcups2, and libglib2.0-0.

Root cause: this is a detection bug, not an install bug

Ubuntu 24.04 renamed these libraries as part of the 64-bit time_t transition, so what actually gets installed is libatk1.0-0t64, libatk-bridge2.0-0t64, libcups2t64, and libglib2.0-0t64. apt install libcups2 still succeeds, because the t64 package provides the old name — that half works.

Detection is where it breaks. installed_dpkg (src/vip/install/packages.py:29-47) shells out to dpkg-query -W -f=${Status} <name> and requires the status to be install ok installed. Queried on the old name, dpkg-query finds no real package by that name and reports nothing installed, because the installed package is the t64 one and the old name only exists as a Provides. So:

1. The plan lists the four old names as missing (debian_packages(), src/vip/install/platform.py:136-141).
2. execute_install_plan prints sudo apt install -y ... and "Then re-run vip install", returning exit code 2 (src/vip/install/runner.py:85-97).
3. apt installs the t64 packages successfully.
4. The re-run queries the old names again, finds them missing again, and returns 2 again. Forever.

Why #251 did not cover this

#251 fixed libasound2 only, and the comment recording that decision (src/vip/install/platform.py:121-125) explains the scoping:

# Ubuntu 24.04+ renamed libasound2 -> libasound2t64 as part of the 64-bit time_t
# transition.  Unlike other t64 renames (libcups2 -> libcups2t64) that apt resolves
# automatically, libasound2 became a virtual package with multiple providers, so
# apt refuses to install it directly.  We swap it for the concrete name on >= 24.04.

That is correct about installing and incomplete about detecting. libasound2 was the case where apt itself refused, so it was the case that surfaced. The other four install fine and then fail the dpkg-query check, which produces a quieter but more confusing symptom — a command that says it succeeded, followed by a tool that insists it did not. _DEBIAN_RENAME_MAP (src/vip/install/plan.py:47) accordingly contains exactly one entry.

Proposal

Both halves belong in this fix, because they solve different problems and the second does not make the first unnecessary.

Name mapping. Generalize _DEBIAN_RENAME_MAP and the substitution in debian_packages() from a single hardcoded swap into a table covering the t64 renames on Ubuntu >= 24.04, so the plan asks apt for the concrete names and then queries the same names it asked for. The four above plus the existing libasound2 are the known set from DEBIAN_PACKAGES; the rest of that list (libpango-1.0-0, libcairo2, libgbm1, libdbus-1-3, the libx* entries) should be checked against noble rather than assumed unchanged. The pending-package normalization at plan.py:53-96 already handles claiming an old recorded name as its new equivalent, so a manifest written by an older VIP keeps working.

Provides-aware detection. Make installed_dpkg treat a package that provides the requested name as satisfying it, so a renamed-but-present library is detected regardless of whether the rename table knows about it. This is the durable half: the rename table needs hand-maintenance at every distro bump and will go stale again on the next LTS, whereas resolving through Provides is how dpkg itself answers the question. It also means the failure mode of a missing table entry becomes "we install a package that was already there" rather than "the installer never terminates".

The mapping alone would resolve the reported symptom, so it can land first if that is easier to review — but shipping only the mapping leaves the same trap armed for 26.04.

Second, smaller problem in the same flow

--skip-system already exists on vip install and is exactly the escape hatch for this situation, including its help text: "Use this when you manage system packages yourself or don't have sudo." The message printed on the failing path never mentions it (src/vip/install/runner.py:95-96):

Not running as root. Please run:
  sudo apt install -y ...
Then re-run `vip install`.

Faced with a loop, the reporter reached for sudo --preserve-env=HOME $(which vip) install instead — running the whole tool as root to get past a check, which is a worse outcome than the flag and required knowing that HOME had to be preserved. Naming --skip-system in that message is a one-line change that gives anyone hitting a detection gap a supported way forward.

Environment

Ubuntu 24.04 LTS, local install mode.