Summary
The Debian package (sub-lode-x_0.2.1_amd64.deb) installs the main executable as /usr/bin/app rather than something project-specific like sublodex or sub-lode-x. This is almost certainly inherited from [package].name = "app" in src-tauri/Cargo.toml, which Tauri uses verbatim as the binary name on Linux (the productName from tauri.conf.json is only used for the .desktop file's Name= field, not for the binary itself).
The .deb itself is correctly named sub-lode-x, and the Start Menu / .desktop entry shows "SubLodeX" — but the actual command the user types (or that scripts invoke) is the very generic app.
Steps to reproduce
- Install the
.deb on a Debian/Ubuntu (or WSL2 Ubuntu) system:
sudo dpkg -i SubLodeX_0.2.1_amd64.deb
- Try to launch it from the terminal using the obvious name:
$ dpkg -L sub-lode-x | grep -E '/(bin|share/applications)/'
/usr/share/applications/SubLodeX.desktop
/usr/bin/bun
/usr/bin/app
Expected vs actual
|
Expected |
Actual |
| Binary path |
/usr/bin/sublodex (or sub-lode-x) |
/usr/bin/app |
.desktop Exec |
Exec=sublodex |
Exec=app |
Why this matters
- PATH collisions.
app is among the most generic possible names for a binary in /usr/bin/. Any other package — present or future — wanting that name will collide with SubLodeX. It's a convention violation: package binaries should be named after the package (or, at minimum, distinctively).
- Discoverability. Users naturally try
sublodex, sub-lode-x, or SubLodeX from the terminal. None of these work. They have to read dpkg -L to figure out the binary is named app. (Personal anecdote: it took me about 10 minutes of poking around before I realized.)
- Scripting / aliases. Anyone writing a wrapper, an alias, or a launcher script ends up referencing
/usr/bin/app, which is hard to read and brittle if (when) it gets renamed.
- Bun sidecar binary (
/usr/bin/bun) has the same issue — it lands in $PATH and could shadow a system-installed Bun. The current package therefore installs two generically-named binaries into $PATH.
Root cause
In src-tauri/Cargo.toml:
[package]
name = "app" # ← becomes the binary filename
version = "0.2.0"
Cargo derives the default binary name from [package].name, and Tauri's bundler uses that name when packaging for Linux. The productName = "SubLodeX" field in tauri.conf.json is correctly used for the user-facing label in the .desktop file, but not for the binary.
Proposed fix
A 2-line change to src-tauri/Cargo.toml:
[package]
name = "sublodex" # was "app"
version = "0.2.1"
# ...
[[bin]]
name = "sublodex"
path = "src/main.rs"
The explicit [[bin]] section makes the binary name independent of the package name (defense in depth in case anyone renames the package later).
For the bundled Bun, the cleanest fix is to install it under /usr/lib/sub-lode-x/ (or similar package-private prefix) rather than /usr/bin/, since it's an internal sidecar and shouldn't be on the user's $PATH at all. This is configurable in tauri.conf.json via the bundle.resources / external binaries section.
After the fix, users would get the natural workflow:
$ sublodex # works
$ which sublodex
/usr/bin/sublodex
The .desktop file's Exec= line should also be updated to match (Tauri does this automatically when the binary is renamed).
Migration consideration
Existing users who upgrade will end up with /usr/bin/sublodex and a stale /usr/bin/app if dpkg doesn't clean it (it should, since the file belongs to the package being upgraded). A note in the release notes ("the command is now sublodex instead of app") would help anyone who has built shell aliases/scripts.
Environment
- OS: Ubuntu 22.04 running under WSL2 on Windows 11
- WSL version: 2.6.3.0, kernel 6.6.87.2-1
- SubLodeX: 0.2.1 (installed from the official
.deb on the v0.2.1 release page)
- Package name:
sub-lode-x
- Binary:
/usr/bin/app (19MB, ELF 64-bit, dynamically linked, x86-64)
Happy to test a fix on WSL2 + standard Ubuntu if it'd help.
Thanks for SubLodeX — really enjoying the project. 🐈
Suggested labels: bug, packaging, linux
Summary
The Debian package (
sub-lode-x_0.2.1_amd64.deb) installs the main executable as/usr/bin/apprather than something project-specific likesublodexorsub-lode-x. This is almost certainly inherited from[package].name = "app"insrc-tauri/Cargo.toml, which Tauri uses verbatim as the binary name on Linux (theproductNamefromtauri.conf.jsonis only used for the.desktopfile'sName=field, not for the binary itself).The
.debitself is correctly namedsub-lode-x, and the Start Menu /.desktopentry shows "SubLodeX" — but the actual command the user types (or that scripts invoke) is the very genericapp.Steps to reproduce
.debon a Debian/Ubuntu (or WSL2 Ubuntu) system:sudo dpkg -i SubLodeX_0.2.1_amd64.deb
$ dpkg -L sub-lode-x | grep -E '/(bin|share/applications)/'
/usr/share/applications/SubLodeX.desktop
/usr/bin/bun
/usr/bin/app
Expected vs actual
/usr/bin/sublodex(orsub-lode-x)/usr/bin/app.desktopExecExec=sublodexExec=appWhy this matters
appis among the most generic possible names for a binary in/usr/bin/. Any other package — present or future — wanting that name will collide with SubLodeX. It's a convention violation: package binaries should be named after the package (or, at minimum, distinctively).sublodex,sub-lode-x, orSubLodeXfrom the terminal. None of these work. They have to readdpkg -Lto figure out the binary is namedapp. (Personal anecdote: it took me about 10 minutes of poking around before I realized.)/usr/bin/app, which is hard to read and brittle if (when) it gets renamed./usr/bin/bun) has the same issue — it lands in$PATHand could shadow a system-installed Bun. The current package therefore installs two generically-named binaries into$PATH.Root cause
In
src-tauri/Cargo.toml:Cargo derives the default binary name from
[package].name, and Tauri's bundler uses that name when packaging for Linux. TheproductName = "SubLodeX"field intauri.conf.jsonis correctly used for the user-facing label in the.desktopfile, but not for the binary.Proposed fix
A 2-line change to
src-tauri/Cargo.toml:The explicit
[[bin]]section makes the binary name independent of the package name (defense in depth in case anyone renames the package later).For the bundled Bun, the cleanest fix is to install it under
/usr/lib/sub-lode-x/(or similar package-private prefix) rather than/usr/bin/, since it's an internal sidecar and shouldn't be on the user's$PATHat all. This is configurable intauri.conf.jsonvia thebundle.resources/ external binaries section.After the fix, users would get the natural workflow:
$ sublodex # works $ which sublodex /usr/bin/sublodexThe
.desktopfile'sExec=line should also be updated to match (Tauri does this automatically when the binary is renamed).Migration consideration
Existing users who upgrade will end up with
/usr/bin/sublodexand a stale/usr/bin/appifdpkgdoesn't clean it (it should, since the file belongs to the package being upgraded). A note in the release notes ("the command is nowsublodexinstead ofapp") would help anyone who has built shell aliases/scripts.Environment
.debon the v0.2.1 release page)sub-lode-x/usr/bin/app(19MB, ELF 64-bit, dynamically linked, x86-64)Happy to test a fix on WSL2 + standard Ubuntu if it'd help.
Thanks for SubLodeX — really enjoying the project. 🐈
Suggested labels:
bug,packaging,linux