Is your feature request related to a problem? Please describe.
Debian and Ubuntu users currently have no project-supported way to install and update Jujutsu through APT. The installation guide offers source builds, downloaded binaries, Cargo Binstall, Homebrew and several distribution-specific packages, but no equivalent to brew install jj or winget install jj for a stock Debian or Ubuntu system.
This has come up previously in #7382, #1952, and most recently PR #9813. The recent Discord discussion also raised an important distinction:
- Packaging Jujutsu for inclusion in Debian or Ubuntu requires following their source-packaging, dependency and Rust-version policies.
- An upstream-owned APT repository can package the official static release binaries and does not impose those constraints on Jujutsu development.
This distinction is not merely theoretical. At the time of writing, Jujutsu's declared MSRV is Rust 1.89, while Debian 13 “Trixie” ships Rust 1.85 in its stable repository. Current Jujutsu releases therefore cannot be built using Trixie's standard Rust toolchain. A package involving backports may be possible, but ordinary packaging for Debian stable is not presently tenable unless Debian provides a sufficiently new compiler in the relevant build environment or Jujutsu lowers its MSRV.
The proposed upstream APT repository avoids that incompatibility by repackaging the official, statically linked release binaries. It does not require Jujutsu to constrain its MSRV to Debian stable or wait for Debian's Rust toolchain to catch up.
The latter is what this issue proposes.
Describe the solution you'd like
Adopt a jj-vcs-owned, signed APT repository for released Jujutsu binaries.
A working proof of concept is available at apt.joshka.net with its implementation at joshka/apt.joshka.net. I am happy to transfer the Jujutsu-specific parts to the project and help complete the handover.
The current implementation:
- Supports Ubuntu 24.04 or newer and Debian 13 or newer.
- Supports
amd64 and arm64.
- Downloads the official static musl artifacts from each
jj-vcs/jj release.
- Verifies them against the SHA-256 digests published with the release.
- Produces signed
jujutsu Debian packages.
- Tests clean APT installations on both architectures before publishing.
- Checks hourly for a new stable release and does nothing when it is already published.
- Retains previous versions so users can pin or hold a known version.
- Uploads only new package payloads; unchanged packages are not uploaded again.
- Uses Debian versions such as
0.43.0-0jj1, allowing a distribution package such as 0.43.0-1 to take precedence naturally.
- Uses only static object storage; it requires no continuously running service.
Releases from 0.30.0 onward have been backfilled, demonstrating that historical versions can also be published without serial release-by-release work.
For this to become a recommended installation method, the project should own the important trust and availability boundaries:
- Repository and automation source
- Public hostname
- Object-storage account or bucket
- APT signing key
- Package maintainer identity
- At least one designated maintainer
A proposed migration is documented in the handover checklist. It includes an overlapping signing-key transition so existing users can migrate without abruptly replacing their trust root.
Once adopted, installation would look approximately like:
curl -fLO https://apt.jj-vcs.dev/jj-archive-keyring.deb
sudo dpkg -i jj-archive-keyring.deb
sudo apt update
sudo apt install jujutsu
The exact hostname and archive-keyring package name are project decisions.
Describe alternatives you've considered
- Official Debian/Ubuntu distribution packages: Desirable independently, but not currently a substitute for an upstream repository. Jujutsu requires Rust 1.89 while Debian 13 “Trixie” provides Rust 1.85 in its stable repository, so current releases cannot be built in the normal Trixie environment. Debian backports may eventually provide a path for a backported package, but release timing, compiler availability, dependency packaging and eventual propagation into Ubuntu remain controlled by the distributions. This proposal neither replaces nor blocks that work.
- An unofficial APT repository: Both the current apt.joshka.net proof of concept and the
deb.griffo.io service proposed in PR #9813 are controlled by individual maintainers rather than the Jujutsu project. deb.griffo.io also plans to require a paid subscription for automatic APT updates from October 2026. Either can technically distribute Jujutsu, but neither provides the project-owned signing identity, governance and long-term availability expected of a blessed installation path.
- Attaching a
.deb to GitHub Releases: Easier to download, but it does not provide repository-managed discovery, upgrades, version retention or pinning.
- Downloading the release archive directly: Works, but leaves installation location, upgrades and removal to the user.
cargo install or Cargo Binstall: Appropriate for many developers, but not equivalent to installing a system tool through the host package manager.- Conda, Pixi, Homebrew or another cross-platform manager: Useful alternatives, but they require introducing a second package manager on otherwise stock Debian/Ubuntu systems.
- A self-update command in
jj: Duplicates package-manager responsibilities and creates ambiguity about which component owns the installed files.
Additional context
This repository would distribute upstream release binaries; it would not claim to be an official Debian or Ubuntu distribution package.
It would also not require Jujutsu to lower its MSRV, package Rust dependencies separately, freeze its release cadence, or wait for 1.0. APT would simply track the same stable releases already published by the project. Users who need stability can use ordinary APT version selection and apt-mark hold.
Ubuntu 22.04 and Debian 12 are deliberately outside the initial support matrix because they ship Git older than Jujutsu's current Git 2.41 runtime requirement. The repository should not take on responsibility for distributing a replacement Git package.
The remaining question is primarily governance rather than implementation: does the project want to own this installation channel and its signing identity? If so, the proof of concept is ready to be moved into project-controlled infrastructure.
Is your feature request related to a problem? Please describe.
Debian and Ubuntu users currently have no project-supported way to install and update Jujutsu through APT. The installation guide offers source builds, downloaded binaries, Cargo Binstall, Homebrew and several distribution-specific packages, but no equivalent to
brew install jjorwinget install jjfor a stock Debian or Ubuntu system.This has come up previously in #7382, #1952, and most recently PR #9813. The recent Discord discussion also raised an important distinction:
This distinction is not merely theoretical. At the time of writing, Jujutsu's declared MSRV is Rust 1.89, while Debian 13 “Trixie” ships Rust 1.85 in its stable repository. Current Jujutsu releases therefore cannot be built using Trixie's standard Rust toolchain. A package involving backports may be possible, but ordinary packaging for Debian stable is not presently tenable unless Debian provides a sufficiently new compiler in the relevant build environment or Jujutsu lowers its MSRV.
The proposed upstream APT repository avoids that incompatibility by repackaging the official, statically linked release binaries. It does not require Jujutsu to constrain its MSRV to Debian stable or wait for Debian's Rust toolchain to catch up.
The latter is what this issue proposes.
Describe the solution you'd like
Adopt a
jj-vcs-owned, signed APT repository for released Jujutsu binaries.A working proof of concept is available at apt.joshka.net with its implementation at joshka/apt.joshka.net. I am happy to transfer the Jujutsu-specific parts to the project and help complete the handover.
The current implementation:
amd64andarm64.jj-vcs/jjrelease.jujutsuDebian packages.0.43.0-0jj1, allowing a distribution package such as0.43.0-1to take precedence naturally.Releases from 0.30.0 onward have been backfilled, demonstrating that historical versions can also be published without serial release-by-release work.
For this to become a recommended installation method, the project should own the important trust and availability boundaries:
A proposed migration is documented in the handover checklist. It includes an overlapping signing-key transition so existing users can migrate without abruptly replacing their trust root.
Once adopted, installation would look approximately like:
The exact hostname and archive-keyring package name are project decisions.
Describe alternatives you've considered
deb.griffo.ioservice proposed in PR #9813 are controlled by individual maintainers rather than the Jujutsu project.deb.griffo.ioalso plans to require a paid subscription for automatic APT updates from October 2026. Either can technically distribute Jujutsu, but neither provides the project-owned signing identity, governance and long-term availability expected of a blessed installation path..debto GitHub Releases: Easier to download, but it does not provide repository-managed discovery, upgrades, version retention or pinning.cargo installor Cargo Binstall: Appropriate for many developers, but not equivalent to installing a system tool through the host package manager.jj: Duplicates package-manager responsibilities and creates ambiguity about which component owns the installed files.Additional context
This repository would distribute upstream release binaries; it would not claim to be an official Debian or Ubuntu distribution package.
It would also not require Jujutsu to lower its MSRV, package Rust dependencies separately, freeze its release cadence, or wait for 1.0. APT would simply track the same stable releases already published by the project. Users who need stability can use ordinary APT version selection and
apt-mark hold.Ubuntu 22.04 and Debian 12 are deliberately outside the initial support matrix because they ship Git older than Jujutsu's current Git 2.41 runtime requirement. The repository should not take on responsibility for distributing a replacement Git package.
The remaining question is primarily governance rather than implementation: does the project want to own this installation channel and its signing identity? If so, the proof of concept is ready to be moved into project-controlled infrastructure.