Make Debian eligible: a version floor of 12, and a reason in is_supported where there is none

[vladimirrott]

docs/distro-support.md:120 already promises this (this issue said line 91 when it was filed; the row has been at 120 the whole time):

| Debian stable/testing | Planned after Ubuntu hardening |

Ubuntu hardening is where it was meant to be: three LTS releases validated at 79/79 on live VMs with committed replay twins. This issue is the follow-through.

What already exists

Debian is not an unrecognised distro. It is a parsed, first-class variant that is deliberately refused:

• DistroId::Debian { version: Option<u32> } (crates/sysknife-core/src/distro.rs:142)
• detect_debian parses VERSION_ID into that field (distro.rs:453)
• family() already returns DistroFamily::Debian for it (distro.rs:205)
• a Debian 12 bookworm fixture and its parse and detect tests exist (distro.rs:643, :764, :958)
• Linux Mint and Pop!_OS already fall back to the Debian family via ID_LIKE

The single line that refuses it (distro.rs:252):

Self::UbuntuCore { .. } | Self::Debian { .. } | Self::Other { .. } => false,

Note what the doc comment above it justifies and what it does not. Pre-20.04 Ubuntu is excluded because it stops receiving security updates. UbuntuCore is excluded structurally, having no apt and a read-only root. Plain Fedora stays detectable so the planner can explain the gap. Debian is given no reason at all. It sits in that arm because nothing has needed it to be elsewhere.

Why it is cheap

Of the 67 Debian-family actions, 57 run on Debian unchanged, and all 97 All
actions already do. That is 154 of 189, ≈ 81.5 %, with no new action code. #237
did the inventory and the list surgery, and it merged as #384 today, so nothing
blocks this now.

Recounted 2026-09-09 at 5673d20. This paragraph said 43 actions and 140
of 189 when it was filed. #237 split the fences, so the 57 now falls out of
the constants directly: DEBIAN_ONLY_ACTIONS (19) plus
NON_CANONICAL_ON_FEDORA (38), leaving behind the 10 in
UBUNTU_ONLY_ACTIONS. The three sets are disjoint and their union is exactly
the 67.

$ python3 - <<'PY'
import re, pathlib, collections
rows=[l for l in pathlib.Path("docs/action-reference.md").read_text().splitlines()
      if re.match(r'^\|\s*`[A-Za-z0-9_]+`\s*\|', l)]
tally=collections.Counter(); noclass=[]
for l in rows:
    fields=[f.strip() for f in l.split('|')]
    hits=[f for f in fields if f in ("All","Ubuntu","Fedora")]
    if len(hits)==1: tally[hits[0]]+=1
    else: noclass.append((fields[1], hits))
print("action rows:", len(rows))
print(dict(tally), "sum:", sum(tally.values()))
print("unclassified:", len(noclass))
PY
action rows: 189
{'Fedora': 25, 'All': 97, 'Ubuntu': 67} sum: 189
unclassified: 0

$ python3 - <<'PY'
import re,pathlib
src=pathlib.Path("crates/sysknife-core/src/action_family.rs").read_text()
def const(name):
    m=re.search(r'pub const '+name+r': &\[&str\] = &\[(.*?)\];', src, re.S)
    return set(re.findall(r'"([A-Za-z0-9_]+)"', m.group(1)))
d,u,n,f=const("DEBIAN_ONLY_ACTIONS"),const("UBUNTU_ONLY_ACTIONS"),const("NON_CANONICAL_ON_FEDORA"),const("FEDORA_ONLY_ACTIONS")
print("sizes", len(d),len(u),len(n),len(f))
print("pairwise overlaps", len(d&u), len(d&n), len(u&n))
print("union of the three", len(d|u|n))
print("runs on Debian unchanged (debian_only + non_canonical)", len(d|n))
PY
sizes 19 10 38 25
pairwise overlaps 0 0 0
union of the three 67
runs on Debian unchanged (debian_only + non_canonical) 57

Recount against the constants rather than trusting either figure, and say in
the PR which number you got. Whether all 57 belong in a Debian support claim
is a judgement about apt behaviour on bookworm, not arithmetic.

The version floor, and the decision it needs

Ubuntu's floor is major >= 20 (the constant at distro.rs:36, the comparison at distro.rs:251) on the stated rationale that older releases stop receiving security updates. Applying the same rule to Debian, with dates from Debian's own release pages:

release	full support ended	LTS ends	eligible under the Ubuntu rule?
11 bullseye	2024-08-14	2026-08-31	no, LTS ended on 2026-08-31
12 bookworm	2026-07-11	2028-06-30	yes, in LTS
13 trixie	2028-08-09	2030-06-30	yes, current stable

So the floor is 12, and OLDEST_SUPPORTED_DEBIAN alongside its Ubuntu sibling is the natural shape.

The part that needs your call: version is Option<u32> because Debian testing and sid publish no VERSION_ID at all, so both parse to None. Debian's security team does not support sid. Refusing None is consistent with the security-updates rationale and is what I would do, but it means Debian stable/testing in the support matrix becomes stable-only, and that row should then be reworded.

Scope

• Add OLDEST_SUPPORTED_DEBIAN: u32 = 12 and give Debian { version } its own arm comparing against it, which also closes a standing gap: the parsed version is currently never compared by any gate, so Debian 11, 12 and 13 are indistinguishable to the whole tree.
• Decide and encode the None case.
• Extend the doc comment on is_supported to state Debian's reason, the way it does for the other three.
• Invert unsupported_debian (distro.rs:1094), which asserts Debian { version: Some(12) } is unsupported. It is a real test, not a vacuous one, so it will fail and should.
• Add os-release fixtures for trixie and for a no-VERSION_ID testing image, following the bookworm fixture at :643.
• Update docs/distro-support.md: the eligibility prose, the tier row, and the wording of the Debian stable/testing line.

Validation before claiming support

Eligibility is not validation, and this repo keeps those apart deliberately. A Debian row should not read Validated until the story suite has run on it, which means ubuntu-vm.sh needs a Debian target or a sibling script. Expect real failures on the first run rather than a clean pass: NetplanGetConfig and GetAuthorizedKeys already fail on stock Ubuntu 24.04 for permission reasons, and Debian's firewall default is nftables rather than ufw (#239).

Recording a live run needs provider credentials, so comment here before starting that part.

Difficulty

medium. The code change is small and the judgement calls plus the validation run are the work.

Getting started

CONTRIBUTING.md has the build and test commands, and docs/distro-support.md explains the eligibility-versus-validation split. No CLA and no copyright waiver. The project is MIT.

[vladimirrott]

@QinXi-ai reserved for you as a follow-up to your recent work; the why is on your PR thread. No pressure and no deadline. Reply here and it is formally yours.

[vladimirrott]

@QinXi-ai releasing this reservation, along with #239.

You are carrying #382, #383 and #384, and #383 has a review from me waiting on a small fix. Holding two more issues on top of that helps nobody: the measurement in this project is that somebody offered a second issue answers exactly one, and I had you down for three.

#238 and #239 read as a pair anyway, since the version floor is what makes the nftables work reachable. They go back to the pool together, and they come back to you together the moment you want them. Land what you have first.

[mikevillari]

Thanks for the follow-up suggestion on #398. I would like to take #238 together with the #239 offer. I will follow #237 / PR #384 rather than overlap the fence split. For this issue I plan to use the Debian 12 floor, reject an unknown version (testing/sid), add the version/detection regressions first, and keep eligibility distinct from live validation in the docs. I will not label Debian validated without an actual story-suite run. Please mark/assign this to me; implementation will start after #384 lands.

[mikevillari]

My availability has changed, so I am releasing my claim on #238 and #239 before implementation. Please leave these available for another contributor. Thank you for the offer and the detailed guidance; the submitted fixes in #398 and #399 remain unaffected.

[vladimirrott]

@QinXi-ai offered this to you on #384 as it merged, and repeating it here so it lives on the issue.

#237 was the stated blocker and you just closed it. This is the follow-through: distro.rs:252 refuses Debian in the same match arm as pre-20.04 Ubuntu and UbuntuCore, and the doc comment above it gives a reason for both of those and none for Debian. It sits there because nothing has needed it elsewhere, and after your PR something does.

The floor works out to 12 on Debian's own dates: bullseye's LTS ended last month, bookworm is in LTS until 2028, trixie is current stable. OLDEST_SUPPORTED_DEBIAN beside its Ubuntu sibling is the shape. Doing that also closes a gap worth more than the eligibility itself, which is that the parsed version is never compared by any gate today, so Debian 11, 12 and 13 are indistinguishable to the whole tree.

One decision is genuinely open, and I would rather you made it than inherited mine. version is Option<u32> because testing and sid publish no VERSION_ID. Debian's security team does not support sid, so refusing None follows the floor's own rationale, and it turns the Debian stable/testing row in the support matrix into stable-only, which then needs rewording. Say which way and the rest is mechanical.

Eligibility is not validation and this repo keeps those apart. A Debian row should not read Validated until the story suite has run on one, and that part needs provider credentials, so comment here before starting it rather than burning an evening. Expect real failures on a first run: NetplanGetConfig and GetAuthorizedKeys already fail on stock Ubuntu 24.04 for permission reasons, and Debian defaults to nftables rather than ufw, which is #239 and belongs to @mikevillari.

Yours if you want it, and no is a complete answer. Say so and I will label and assign it.

[vladimirrott]

@mikevillari releasing your claim here, and #239 with it. Telling me before you started rather than after is the version of this that costs nobody an evening, and I would take that over a branch any day.

#395 is still yours with #399 open against it, so nothing changes there.

[QinXi-ai]

I'll take this as the follow-up to #384. I'll use a Debian version floor of 12 and reject an unknown version (None), with bookworm/trixie and testing fixtures and the corresponding stable-only eligibility wording. Eligibility will remain explicitly separate from live validation.

Please assign this to me. Before attempting the live Debian story suite, what existing Debian VM/provider setup should I use, or would you prefer to run that part? I can complete the eligibility change and local checks first; I will not label Debian validated without a measured run. Codex is assisting with implementation and validation.

[vladimirrott]

Closed by #412, merged as a0b60fc7.

Closing by hand because that pull request declared no Closes keyword, so GitHub did not do it. Recording the resolution rather than leaving the thread to be worked out later:

OLDEST_SUPPORTED_DEBIAN = 12, Debian gets its own arm in is_supported, and an absent VERSION_ID is refused. @QinXi-ai made the open call on None and gave the reasoning, which is what I asked for rather than inheriting mine. The support matrix says "Current validation required" instead of claiming a live run, because eligibility is not validation and this repo keeps those apart.

Measured on the merged catalogue: a Debian 12 planner receives 136 of 190 actions, with zero leaks from UBUNTU_ONLY_ACTIONS, NON_CANONICAL_ON_DEBIAN_HOST, NON_CANONICAL_ON_DEBIAN or FEDORA_ONLY_ACTIONS. The 24 it does not receive are exactly the Ubuntu-identity set plus the tools Debian does not ship by default.

The validation half stays open and is not this issue. A Debian row does not read Validated until the story suite has run on one, and that needs provider credentials.