86655eac66
* fix(hopper): keep automated Linux setup off non-x86_64 hosts Every pinned Linux Hopper package (deb, rpm, Arch) is x86_64-only, but hopperSetupSupported was derived from os-release alone. Setup therefore planned and confirmed an amd64 package install on arm64 Ubuntu 24.04 and the other tested distributions. Classify installer support with the host architecture where the distribution is parsed, so setup planning, preflight, installation and package verification share one decision. Setup now takes its Linux distribution from the doctor host, as it already does for the macOS version, and the supported-host remediation text has a single owner. Fixes #3419 * fix(hopper): install Linux Hopper from the setup host's distribution facts systemLinuxHopperInstallHost read os-release with process.arch on its own, while setup planning used the doctor host's injected architecture. Both agree in production, but a doctor host composed with another architecture could plan one answer and install with another. The install host now takes its distribution reader from the caller, and systemSetupHost passes the doctor host's, so planning, preflight and installation share one host-fact owner. The unused default host on installLinuxHopper, the other ambient reader, is removed. * fix(verify-package): require Hopper readiness only where Linux setup installs it packageSetupSupport required doctor Hopper readiness on every Linux host whose host check passed, including installer-untested distributions and, after the architecture gate, arm64 hosts where setup never provides Hopper. On Linux, readiness now also requires automated installer applicability; macOS is unchanged. This narrows the readiness assertion from #2973 on hosts outside the installer matrix, such as Kali and ubuntu-24.04-arm. --------- Co-authored-by: DavidFB-creator <220631175+DavidFB-creator@users.noreply.github.com> Co-authored-by: Kaoru0822 <208281322+kaoru0822-kitauji@users.noreply.github.com>
40 lines
1.3 KiB
TypeScript
40 lines
1.3 KiB
TypeScript
/**
|
|
* Host facts the packaged setup support is derived from.
|
|
*
|
|
* `linuxDistribution` is the distribution record the Hopper installer owner
|
|
* parses; it is absent when no distribution could be read, which leaves
|
|
* installer applicability unknown rather than unsupported.
|
|
*/
|
|
export interface SetupHostFacts {
|
|
readonly platform: NodeJS.Platform;
|
|
readonly linuxDistribution?: {
|
|
readonly hopperSetupSupported: boolean;
|
|
};
|
|
}
|
|
|
|
/**
|
|
* Derive agent setup support from the doctor node check and automated Hopper
|
|
* installer applicability from the facts their owners parse. Applicability is
|
|
* undefined when its owning fact is unavailable. On Linux, Hopper readiness is
|
|
* required only where the automated installer applies.
|
|
*/
|
|
export function packageSetupSupport(
|
|
checks:
|
|
| readonly { readonly name: string; readonly ok: boolean }[]
|
|
| undefined,
|
|
host: SetupHostFacts,
|
|
): {
|
|
supportedSetupHost: boolean;
|
|
hopperReadinessRequired: boolean;
|
|
hopperSetupSupported: boolean | undefined;
|
|
};
|
|
|
|
/** Validate --help, --llms, and doctor output and determine host setup support. */
|
|
export function verifyPackageDiscovery(input: {
|
|
readonly cli: string;
|
|
readonly environment: Readonly<Record<string, string | undefined>>;
|
|
}): Promise<{
|
|
supportedSetupHost: boolean;
|
|
hopperSetupSupported: boolean | undefined;
|
|
}>;
|