replace hard coded distro-name checks with platform capability detect

[VectorSophie]

Summary

replace distribution-name-specific behavior with a platform capability abstraction.

LUD currently contains logic that identifies distributions using checks such as Ubuntu vs Pop!_OS and otherwise falls back to Unknown.

other actions implicitly assume particular components such as:

• APT
• GRUB
• update-grub
• kernelstub
• systemd
• GNOME/gsettings
• Debian package formats

makes behavior depend on distro names even when the actual requirement is a particular package manager, boot configuration system, init system, desktop environment or system capability.

So what

introduce a platform abstraction that detects the facilities available on the host and allows actions to declare what they require.

example:

Platform
├── package manager
│   ├── apt
│   ├── dnf
│   ├── pacman
│   └── unsupported
├── boot configuration
│   ├── grub
│   ├── kernelstub
│   ├── systemd-boot
│   └── unsupported
├── init
│   ├── systemd
│   └── unsupported
├── desktop/settings
│   ├── GNOME
│   ├── KDE
│   └── other
└── audio/session stack
    ├── PipeWire
    ├── PulseAudio
    └── unknown

actions could check a capability instead of a distro name.

example:

instead of:

if distribution == "Ubuntu":
    ...

behavior should resemble:

if platform.has("glib-compile-schemas"):
    ...

or:

platform.package_manager.install(...)

similar, kernel command-line changes should target a detected boot configuration backend instead of assuming /etc/default/grub.

Proposal

Platform detect

centralized object/module responsible for determining:

• OS metadata
• package manager
• boot configuration backend
• init/service manager
• relevant desktop configuration backend
• available helper commands

Package BE

initial implementation:

AptBackend

future implementations may be:

PacmanBackend
DnfBackend

Boot BE

possible interface:

get_kernel_parameters()
add_kernel_parameters(...)
remove_kernel_parameters(...)
apply()

initial implementations could do:

• GRUB
• kernelstub

with systemd-boot added independently later.

Why

project is already being used beyond environment inherited from System76.

capability model would:

• reduce distro-specific branching
• prevent inappropriate commands on unsupported distributions
• make support for additional distributions incremental
• simplify testing
• make --plan output more accurate
• make hardware actions less coupled to Ubuntu/Pop!_OS assumptions

Tests

platform detect should use fixtures/mocks rather than depending on the CI host.

tests should cover representative environments such as:

• Ubuntu + APT + GRUB
• Pop!_OS + APT + kernelstub
• Debian + APT + GRUB
• non-Debian system with unsupported package backend
• system without supported boot configuration

[VectorSophie]

grounded this one too. the actual checks today:

• get_distribution() — system76driver/actions.py:977-996 — string-matches lsb_release-style Description output, returns 'Ubuntu' / 'Pop' / 'Unknown'
• consumers: energystar_gsettings_override.get_isneeded() (actions.py:1021-1022) and energystar_wakeonlan.get_isneeded() (actions.py:1081) both gate purely on get_distribution() != 'Ubuntu', even though what they actually depend on is "does gsettings/glib-compile-schemas exist," not "is this Ubuntu"
• GrubAction.__init__ (actions.py:341-347) is already halfway to a capability check — it does if path.isfile('/usr/bin/kernelstub') rather than checking distro name at all

so this isn't "add an abstraction that doesn't exist yet," it's "generalize the one correct pattern already in the file (GrubAction) and retire the distro-string one (get_distribution) the other call sites lean on."

Alternatives considered

keep get_distribution(), add more elif branches per distro — rejected, doesn't scale past Ubuntu/Pop, and still couples an unrelated concern (does gsettings exist) to a distro name instead of the actual dependency.

full plugin system, per-distro packages registered via entry points — rejected as overkill for what's currently one package manager (apt) and two boot backends (grub/kernelstub) in the whole codebase. a plain detect module covers it until there's a second real backend to support.

env/CLI override for forcing a capability in tests — keeping this one. system76-driver-cli already has --model to force model detection instead of probing hardware; a --platform-style override for tests/CI follows the same precedent and makes the "system without supported boot configuration" case in the issue easy to drive without mocking three layers deep.

[tpm28]

like I already said, I had started modifying LUD a lot for this kind of thing and I think I'd already thought about it... I had it on my PC locally but so you can see it I just put it on a repo of my own, I hope this will be temporary but there it is

https://github.com/felix068/linux-universal-driver-V2