feat: minimum codenames

[silentJET85]

closes #1798
This will allow you to append a + to a codename in the CODENAMES_SUPPORTED variable, to specify it as the minimum supported codename. This way most packages won't need to be updated every six months when a new Ubuntu is released.

For example instead of:
CODENAMES_SUPPORTED="trixie forky sid noble questing resolute"
you could instead do:
CODENAMES_SUPPORTED="trixie+ noble+"

[cubic-dev-ai]

1 issue found across 1 file

Confidence score: 3/5

• There is a concrete medium-high risk issue (severity 7/10, confidence 9/10): in deb-get, + codename expansion can become empty for unknown/minimum codenames, which then gets treated as unrestricted support.
• This can silently bypass codename gating, creating real regression risk in support checks rather than a cosmetic or housekeeping concern.
• Given the high confidence and user-impacting behavior change, this is not fully merge-blocking but carries enough uncertainty to warrant caution before merge.
• Pay close attention to deb-get - ensure empty codename expansion cannot be interpreted as unrestricted support.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="deb-get">

<violation number="1" location="deb-get:492">
P1: `+` codename expansion can collapse to empty for unknown/minimum codenames, and empty is then treated as unrestricted support, silently bypassing codename gating.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="deb-get">

<violation number="1" location="deb-get:490">
P2: Malformed minimum-codename parse now returns success early, causing `validate_deb` to skip required validation checks.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[silentJET85]

I think adding distro-info-data as a dependency is a good idea.

It would also allow us to altogether remove the need to manually add support for new codenames as they release. Though I'll save that for a different pull request.

[cubic-dev-ai]

1 issue found across 2 files

Confidence score: 3/5

• There is a concrete medium-high risk issue: in deb-get, codename expansion can fail open, clearing codename restrictions when minimum codename lookup returns no match.
• Because this is severity 7/10 with high confidence (9/10), it could cause unsupported packages to be treated as universally supported, which is user-impacting behavior rather than a minor edge-case cleanup.
• Pay close attention to deb-get - verify codename lookup failure paths preserve restrictions instead of defaulting to unrestricted support.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="deb-get">

<violation number="1" location="deb-get:492">
P1: `+` codename expansion fails open: if minimum codename lookup finds no match, codename restrictions are cleared and package may be treated as universally supported.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[snoack]

The new syntax should probably be documented in EXTREPO.md.

[cubic-dev-ai]

0 issues found across 1 file (changes from recent commits).

_{Requires human review: This is a new feature that modifies core package validation logic using complex shell string manipulation and external data dependencies.}

[philclifford]

Just a thought: I wonder if making the dependency on distro-info and using e.g. echo $(${UPSTREAM_ID}-distro-info --supported) is an even better option : that way we get dynamically listed supported releases and not just new ones and don't have to bother with parsing the csv directly.

[silentJET85]

Yeah, I think that could work.

And as a bonus, having the distro-info command available could come in handy to use in some packages. Such as when we need to fall back to a deb file or repo meant for a previous release.
That way we don't have to hardcode which codenames to fallback to, or just blindly decrementing UPSTREAM_RELEASE and hoping for a match, as I've been doing.

[silentJET85]

I've found one problem with the --supported flag. It doesn't consider releases in Debian's LTS support period to be "supported." In other words, Bullseye is missing.

jet@devuan:~$ distro-info --supported
bookworm
trixie
forky
sid
experimental

EDIT: I came up with a workaround. If we run distro-info a second time, but with the --all flag, we can grep for the previous output and grab the line that occurs before it. It should be safe to assume that the line preceding the list of "supported" releases will be the one currently in LTS support.

[silentJET85]

@cubic-dev-ai Can you re-review this?

[cubic-dev-ai]

@cubic-dev-ai Can you re-review this?

@silentJET85 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Requires human review: This PR modifies core validation logic and package dependencies, introducing dynamic codename resolution that requires human verification to ensure it doesn't break package installations.}

[silentJET85]

This needs one final tweak. Using distro-info --supported to get our list of distros, results in CODENAMES_SUPPORTED being blank if a package has an outdated release set as it's minimum.

EDIT: I have changed it to use distro-info --all instead. I think this is the simplest solution.

The only side effect would be that some packages could potentially continue working even when running on an EOL distro.
In packages where CODENAMES_SUPPORTED is unset, that would happen anyway. So it doesn't seem like a big deal.

[cubic-dev-ai]

1 issue found across 2 files

Confidence score: 3/5

• There is a concrete regression risk in deb-get: the + codename fallback can clear CODENAMES_SUPPORTED, and empty codename lists are then treated as unrestricted support.
• Because this is severity 7/10 with high confidence (9/10) and could allow unsupported releases, it has real user-facing impact even though the change scope appears limited.
• This PR may still be mergeable with a quick guard/fix, but it carries moderate risk until codename handling is tightened.
• Pay close attention to deb-get - codename fallback and empty-list logic can incorrectly permit unsupported distributions.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="deb-get">

<violation number="1" location="deb-get:494">
P1: `+` codename fallback can clear `CODENAMES_SUPPORTED`, and empty codename lists are treated as unrestricted support, potentially allowing unsupported releases.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}