In a --target build, the extracted precompiled binary is placed under target/<triple>/release/models, but the cargo-deb assets list points at target/release/models. This mismatch will make cargo deb --no-build --target ... fail (missing asset) or accidentally package the wrong binary. Align the asset source path with where the workflow places the binary (or adjust the workflow to copy/symlink the binary to target/release/models before running the packagers).

Same issue as the deb metadata: the RPM asset source is set to target/release/models, but the workflow stages the prebuilt binary under target/<triple>/release/models for --target runs. Update the asset source path or adjust the workflow staging so generate-rpm can find the file for both architectures.

The latest/download/ URL already selects the latest release, but the filename shown still includes a <version> placeholder, which users won’t know for “latest”. Either switch the example to the tag-based URL (.../download/v<version>/...) or show a command that resolves the latest version / asset name automatically (and consider documenting both amd64 and arm64 filenames if you’re publishing both).

Same problem as the .deb instructions: the example uses latest/download/ but also a <version> placeholder in the filename. Consider switching to a tag-based URL or providing a snippet that discovers the latest asset name, and document the aarch64 RPM filename if it’s being published.

This PKGBUILD downloads release artifacts but sets all sha256sums* fields to SKIP, which disables integrity verification for the binary tarballs. For a binary-distribution package, it’s safer (and generally expected) to pin the actual SHA256 sums for each architecture and update them when bumping pkgver.

For a VCS (-git) PKGBUILD, pkgver is expected to be derived from pkgver(); hardcoding pkgver=0.9.7 can make the AUR metadata look stale/misleading even though pkgver() will override it during builds. Consider using a conventional placeholder (e.g., pkgver=0.0.0) and relying on pkgver() for the real version.

The prebuilt binary is extracted into target/${{ matrix.target }}/release/, but the packaging metadata in Cargo.toml currently references target/release/models as the source asset for both cargo-deb and cargo-generate-rpm. Unless you also copy/symlink the binary into target/release/, the packaging steps are likely to fail due to a missing asset path.

The Debian/Ubuntu and Fedora/RHEL install instructions download and install .deb/.rpm packages directly from GitHub over HTTPS without any checksum or signature verification, which creates a supply chain risk. If an attacker compromises the release artifacts or the delivery channel, users following these commands could end up executing a malicious package with elevated privileges. Consider updating these instructions to include integrity verification (e.g., GPG-signed packages or published checksums that users verify before running dpkg/rpm) or to use a signed repository-based installation method instead.

The README says each GitHub Release includes SHA256 checksums in the release assets, but the release workflow only computes hashes for updating the Homebrew formula and does not upload a checksum file to the GitHub Release. Either adjust this wording or add a workflow step to generate and attach a checksums file (covering the .deb/.rpm too, if desired).

The release workflow installs cargo-deb and cargo-generate-rpm via cargo install without pinning versions or using --locked, which can make releases non-reproducible and can break when upstream crates publish incompatible updates. Consider pinning tool versions and adding --locked (and optionally caching) to keep packaging stable over time.

In the binary AUR package, the LICENSE is fetched from the moving main branch. That makes builds non-reproducible and can break checksum verification when the LICENSE changes. Prefer fetching the LICENSE from the same immutable release tag (or include it in the release tarball) so it stays aligned with pkgver.

The source_x86_64 and source_aarch64 entries download pre-built binaries from GitHub Releases, but all of the corresponding sha256sums* arrays are set to SKIP, so makepkg performs no integrity verification of the executables. If an attacker tampers with the release assets or the download path, users will transparently install and run attacker-controlled binaries. Replace the SKIP entries with real SHA256 checksums for each architecture (and keep them updated per release) so that package builds fail on unexpected changes.

The flake inputs flake-utils and naersk are referenced via mutable GitHub URLs (github:numtide/flake-utils and github:nix-community/naersk) without a committed flake.lock or other pin to specific revisions, so builds will always execute the latest code from those third-party repos. If either upstream or its GitHub ref is compromised, running nix build/nix run on this flake could silently produce malicious binaries or otherwise tamper with build outputs. Pin these inputs to specific revisions via a checked-in flake.lock (or explicit rev/ref attributes) to make builds deterministic and protect against upstream supply-chain compromise.