Stop the Debian version from claiming a false order #328

Open
PerishFire wants to merge 1 commit from task/a-deb-version-that-sorts into main
Owner

debian.rs wrote the semver string into the dpkg Version field verbatim. dpkg does not read it as semver: - separates upstream_version from debian_revision, and an empty revision sorts below a present one, so the prerelease claims to be newer than the release it precedes.

dpkg --compare-versions 0.27.0-beta.1 '>>' 0.27.0            # true
dpkg --compare-versions 0.27.0~beta.1 '<<' 0.27.0            # true
dpkg --compare-versions 0.26.0        '<<' 0.27.0~beta.1     # true
dpkg --compare-versions 0.27.0~beta.10 '>>' 0.27.0~beta.9    # true

Scope, said plainly rather than inflated. Nobody is hit by this today. There is no apt repository anywhere in this release path — none is generated, none is served. The installer fetches the .tar.gz, checksums it, and unpacks it; it never touches the .deb. dpkg appears in this repository only where the package is built and its contents are read back. The field has no reader inside anything Plumb operates.

What remains is narrow and still worth six lines: the .deb is published to a public authority, so someone can put it in an apt repository of their own, and on that day the order it asserts is wrong. A published artifact should not carry a claim that is false the moment anything reads it.

Only the first - becomes a tilde, so a prerelease carrying its own hyphen keeps it.

No unit test: the function is private, the [lib] target is a one-file shim that cannot reach it, and engine/ and tests/ both sit exactly at the fanout limit. The comparisons above were run, not remembered.

`debian.rs` wrote the semver string into the dpkg Version field verbatim. dpkg does not read it as semver: `-` separates upstream_version from debian_revision, and an empty revision sorts below a present one, so the prerelease claims to be newer than the release it precedes. ``` dpkg --compare-versions 0.27.0-beta.1 '>>' 0.27.0 # true dpkg --compare-versions 0.27.0~beta.1 '<<' 0.27.0 # true dpkg --compare-versions 0.26.0 '<<' 0.27.0~beta.1 # true dpkg --compare-versions 0.27.0~beta.10 '>>' 0.27.0~beta.9 # true ``` **Scope, said plainly rather than inflated.** Nobody is hit by this today. There is no apt repository anywhere in this release path — none is generated, none is served. The installer fetches the `.tar.gz`, checksums it, and unpacks it; it never touches the `.deb`. `dpkg` appears in this repository only where the package is built and its contents are read back. The field has no reader inside anything Plumb operates. What remains is narrow and still worth six lines: the `.deb` is published to a public authority, so someone can put it in an apt repository of their own, and on that day the order it asserts is wrong. A published artifact should not carry a claim that is false the moment anything reads it. Only the first `-` becomes a tilde, so a prerelease carrying its own hyphen keeps it. No unit test: the function is private, the `[lib]` target is a one-file shim that cannot reach it, and `engine/` and `tests/` both sit exactly at the fanout limit. The comparisons above were run, not remembered.
Give the Debian package a version that sorts
All checks were successful
guard / guard (pull_request) Successful in 2m56s
879f668df1
`debian.rs` wrote the semver string into the dpkg Version field verbatim, and
dpkg does not read it as semver. `-` there separates upstream_version from
debian_revision, and an empty revision sorts below a present one, so the
prerelease came out newer than the release it precedes:

    dpkg --compare-versions 0.27.0-beta.1 '>>' 0.27.0     # true

Apt would have offered a beta as an upgrade over the stable that supersedes it,
which is the whole of what a version field is for. `~` is the one character
that sorts below everything including the empty string, and it is what Debian
uses for exactly this:

    dpkg --compare-versions 0.27.0~beta.1 '<<' 0.27.0     # true
    dpkg --compare-versions 0.26.0 '<<' 0.27.0~beta.1     # true
    dpkg --compare-versions 0.27.0~beta.10 '>>' 0.27.0~beta.9  # true

Only the first `-` becomes a tilde. What follows is the prerelease as semver
wrote it, so a prerelease that carries its own hyphen keeps it.

No unit test comes with this. The function is private, the `[lib]` target is a
one-file shim that cannot reach it, and both `engine/` and `tests/` sit exactly
at the fanout limit — the two places a new file would have gone. Spending both
budgets to reach a six-line function is the wrong trade; the ordering claims
above are what this rests on, and they were run rather than remembered.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PerishFire changed title from Give the Debian package a version that sorts to Stop the Debian version from claiming a false order 2026-08-18 13:32:18 +00:00
PerishFire force-pushed task/a-deb-version-that-sorts from 879f668df1
All checks were successful
guard / guard (pull_request) Successful in 2m56s
to b1d8589418
All checks were successful
guard / guard (pull_request) Successful in 3m49s
2026-08-18 13:32:18 +00:00
Compare
All checks were successful
guard / guard (pull_request) Successful in 3m49s
This pull request has changes conflicting with the target branch.
  • plumb.toml
View command line instructions

Manual merge helper

Use this merge commit message when completing the merge manually.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin task/a-deb-version-that-sorts:task/a-deb-version-that-sorts
git switch task/a-deb-version-that-sorts
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
PerishLab/plumb!328
No description provided.