chore(packaging): decide the fate of debian/, which is maintained every release but has never shipped and cannot build

[inureyes]

Problem / Background

The debian/ directory carries a complete Launchpad PPA packaging setup that is updated on every release, has never produced a published package, and could not build on any current Ubuntu series even if it were uploaded. It needs either a revival or a removal, not continued maintenance in its present state.

Evidence 1: nothing has ever been published

The target PPA is lablup/backend-ai (hardcoded as the default in debian/update-changelog.sh:14 and debian/get-next-ppa-version.sh). Querying the Launchpad API for that archive:

• Published sources: all-smi and bssh only, each for jammy, noble and resolute.
• source_name=mlxcel across all statuses, including superseded and deleted: total_size: 0. It has never been uploaded.
• source_name=rustc and source_name=cargo: total_size: 0. The PPA hosts no toolchain package of its own.

Evidence 2: no workflow uploads it

.github/workflows/release.yml contains zero occurrences of dput, ppa, launchpad or debian. Its jobs are build-macos, build-linux-cuda, build-linux-x86_64-cuda, notify-teams, promote-release and generate-sbom. No other workflow references the PPA either.

debian/README.packaging nevertheless states, under "Automatic Version Incrementing": "GitHub Actions: Automatically uses version incrementing when uploading to PPA". That describes a workflow that does not exist and should be corrected or removed whichever path is taken.

Evidence 3: it is maintained on every release regardless

debian/changelog is 68 KB and holds 42 entries, all targeting jammy. It is regenerated by debian/update-changelog.sh, whose default distro is jammy (line 12). Recent commits touching it are 986c5207 chore(release): prepare v0.5.0-beta.1, ba9101bd chore(release): v0.4.3, 1b9a0018 chore(release): v0.4.2. So release preparation keeps paying a maintenance cost for an artifact with no consumer.

Evidence 4: the build dependency is unsatisfiable on every current series

debian/control and debian/control.source both declare Build-Depends: ..., rustc (>= 1.85), cargo (>= 0.85), .... The project uses edition 2024, which is why 1.85 is the floor.

Ubuntu archive contents for the unversioned rustc source package, measured against the Launchpad API:

Series	Unversioned rustc	Satisfies >= 1.85
jammy	1.58.1, 1.75.0	no
noble	1.75.0	no
plucky	none published	no
questing	none published	no
resolute	none published	no

The newer series ship only version-suffixed source packages, which a rustc (>= 1.85) dependency does not resolve to:

Series	Versioned packages
plucky	rustc-1.81, rustc-1.82, rustc-1.83, rustc-1.84, rustc-1.85
questing	rustc-1.85, rustc-1.88, rustc-1.91
resolute	rustc-1.91, rustc-1.92, rustc-1.93

So the declared build dependency cannot be satisfied anywhere: the two series that publish an unversioned rustc are both stuck at 1.75, and the three that are new enough publish no unversioned rustc at all. The changelog's own target, jammy, is the worst case.

debian/README.packaging already concedes part of this in its "Rust Version Requirements" section, but its per-series guidance is now out of date.

Evidence 5: the rustup escape hatch cannot work on Launchpad

debian/rules.launchpad tries curl https://sh.rustup.rs | sh when rustc is absent. debian/README.packaging documents, correctly and in its own words, that "Launchpad build environments do NOT have internet access". That path is dead by construction. debian/rules (the active one) is the system-toolchain variant and does not attempt it.

Evidence 6: the toolchain pin does not help and the gap just widened

rust-toolchain.toml is a rustup feature. The cargo shipped in the Ubuntu archive is not a rustup proxy and ignores the file, so the pin neither helps nor hinders a PPA build; the effective compiler would be whatever the build dependency resolves to.

Separately, #1066 moved the pin from 1.93.1 to 1.97.1 and CONTRIBUTING.md now states a minimum of Rust 1.97+. debian/control still says 1.85. Whatever happens to debian/, that inconsistency exists as of today. Note also that the workspace has no rust-version field in Cargo.toml, so the project's real MSRV is unenforced and currently unknown; the highest thing any Ubuntu series offers is resolute's rustc-1.93, which is below the pin.

Proposed Solution

Pick one of two mutually exclusive paths. Path B is the larger piece of work and should not be started without a decision that Ubuntu packaging is wanted. Until one of the two paths is taken, the release process keeps updating a file that nothing consumes.

Path A: remove it

Delete debian/, stop regenerating debian/changelog during release preparation, and drop the PPA claims from any docs that mention them. Justified if Linux distribution is served adequately by the release binaries that release.yml already builds.

Path B: revive it

Retarget the packaging at a series whose archive can actually build the tree, fix the build dependency so it resolves against real archive contents, prove an offline vendored build on a Launchpad builder, and wire the upload into the release process so it stops rotting.

Acceptance Criteria

Path A (remove)

• debian/ removed.
• No release-preparation step or skill still writes debian/changelog.
• No document claims a PPA exists or that CI uploads to one.

Path B (revive)

• Retarget debian/changelog off jammy to a series whose archive can actually build the tree.
• Replace rustc (>= 1.85) with a dependency that resolves against real archive contents, for example an alternation over the versioned packages available on the target series.
• Establish the project's true MSRV and record it as rust-version in Cargo.toml, then confirm it is at or below the highest rustc the target series provides (currently rustc-1.93 on resolute).
• Confirm the build works with vendored dependencies and no network, since Launchpad builders have none. debian/prepare-source-package.sh already vendors via cargo vendor, but this has never been exercised on a builder.
• Add the upload step to release.yml so the packaging is exercised by the release process rather than only by hand.
• Verify a real published build on the PPA before closing.
• Correct debian/README.packaging, including the false claim that GitHub Actions uploads to the PPA and the stale per-series Rust guidance.

Technical Considerations

Whichever path is chosen, the debian/control floor of 1.85 is already inconsistent with the 1.97.1 toolchain pin from #1066 and the Rust 1.97+ minimum stated in CONTRIBUTING.md. Path A resolves it by deletion; Path B has to resolve it by establishing and recording a real MSRV.