Files
narOS/mkimage/profiles/vm-desktop.pkgs
T

83 lines
3.6 KiB
Plaintext

# naros-vm DESKTOP flavor — Debian package list (NAROS.md §7.4, milestone N5).
#
# Built entirely from a pinned Debian FORKY snapshot (build-rootfs.sh maps vm-desktop→forky)
# because forky ships GNOME 50 / Mutter 50 — the compositor the semantic agent targets —
# while trixie is stuck at GNOME 48. One coherent forky pocket, no trixie/forky ABI mixing.
#
# The GNOME 50 stack is BAKED here at build time (not pulled at firstboot): the whole desktop
# rootfs is one CI-built pocket, so a base build never drags ~1.5 GB from snapshot.debian.org.
# These are apt --include'd (dependencies resolved from forky); the Nucleic layer + tier metas
# configure last (vm-desktop.late-pkgs) so the nash divert stays the final step.
#
# No linux-image — external kernel + its modules ride the two-phase payload (LINUX_VM.md).
# systemd as PID 1 (§5: the VM desktop flavor keeps systemd) + networking/udev/dbus/sudo.
systemd
systemd-sysv
systemd-resolved
udev
# kmod (depmod/modprobe) is required even though no linux-image is — see vm.pkgs for the full
# reasoning. Short version: --variant=apt skips priority:important, udev pulls only libkmod2, and the
# external kernel's modules arrive with no modules.dep, so nucleic-modsetup needs depmod/modprobe to
# load vsock (a MODULE on modern Ubuntu kernels). Without it the guest agent can never bind AF_VSOCK.
kmod
dbus
dbus-user-session
sudo
# GNOME 50 Wayland session: shell/Mutter + GDM auto-login, a couple of GTK4 reference apps so
# a fresh screenshot isn't an empty desktop, XWayland for X clients, Mesa for software GL.
gnome-session
gnome-shell
gnome-shell-extension-prefs
gdm3
gnome-console
gnome-text-editor
xwayland
libgl1-mesa-dri
# Accessibility stack — the AT-SPI D-Bus registry the semantic agent consumes, plus the GI
# bindings its Python/host tooling uses, and the settings/dconf plumbing for system defaults.
at-spi2-core
gsettings-desktop-schemas
dconf-cli
python3-gi
gir1.2-atspi-2.0
# Reference browsers for computer-use / the semantic agent. Debian ships a real Firefox deb
# (unlike Ubuntu's snap shim), so no Mozilla-apt dance is needed — firefox-esr from forky.
#
# chromium is the Linux "chrome" target (MacVMEngine+Computer.swift `knownBrowsers`). It is NOT
# Chrome for Testing, which the macOS base installs: Google publishes CfT for linux64 (x86_64)
# only, and this rootfs is arm64-only (the guest runs on Virtualization.framework), so there is no
# arm64 CfT build to bake. Debian's chromium is the same Blink/V8 engine built natively for arm64,
# so `open_browser "chrome"` resolves to a real Chromium on both guests. Launched with
# --force-renderer-accessibility so its AT-SPI tree is populated for ax_* (see naros-desktop-config).
firefox-esr
chromium
fonts-dejavu-core
# Modest dev toolchain, mirroring the guest it replaces (agents also exec/build in the VM).
build-essential
git
curl
ca-certificates
openssh-client
iproute2
jq
python3
python3-venv
python3-pip
nodejs
npm
# Swift, from forky's own swiftlang (6.2.3 in the pinned snapshot) rather than the swift.org
# release tarball the container image bakes (6.3.3, os/images/agent/Dockerfile). Not a
# preference for older — the upstream builds are simply unloadable here: every swift.org slice
# links libxml2.so.2, and forky replaced libxml2 with libxml2-16 (soname .so.16, no versioned
# symbols to alias), so swift-build/swift-test die in the loader. Debian's package is built
# against forky's own libxml2-16 and python3.14, which also means its LLDB works — the piece
# the container layer has to strip. Same rule as the GNOME stack above: one coherent pocket,
# no trixie/forky ABI mixing. ~2.6 GB installed.
swiftlang