[Bug]: Linux install improvements for Debs and systemd
- Dominant language
- Rust
- Stars
- 21k
- Forks
- 675
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 172
Description
### Pre-flight checklist
- [x] I searched [existing issues](https://github.com/AprilNEA/OpenLogi/issues?q=is%3Aissue) and this is not a duplicate.
- [x] I am on the [latest release](https://github.com/AprilNEA/OpenLogi/releases/latest) or a recent `master` build.
- [x] I quit **Logi Options+** before running OpenLogi (the two apps fight over HID++ access and only one can own a receiver at a time).
### Which part of OpenLogi?
Not sure
### OpenLogi version
Install-time issues
### Operating system
Linux
### OS version & architecture
Ubuntu 26.04
### Device model
Install-time issues
### How is the device connected?
Other / not sure
### Affected area(s)
- [ ] Device discovery / detection
- [ ] Button remapping
- [ ] DPI control
- [ ] SmartShift
- [ ] Per-application profiles
- [ ] Battery status
- [ ] Settings / configuration (TOML)
- [ ] Auto-update
- [ ] Menu bar / tray
- [x] Other
### What happened?
Hey, this looks like a cool system! While trying it out, I found a few quality of life papercuts on Linux that you might want to address.
First, the 'easy install' command line (`sudo dpkg -i openlogi_*.deb`) as specified in https://github.com/AprilNEA/OpenLogi#linux and https://openlogi.org/docs/getting-started/installation#linux doesn't work because you've changed the separator on the Debian releases (at least) from an underscore to a dash.
Second, the instructions [for autostart](https://github.com/AprilNEA/OpenLogi/blob/master/docs/INSTALL-linux.md#autostart-launch-at-login) say that the user unit is installed in `~/.config/systemd/user/openlogi-agent.service` automatically upon setting a GUI option. This is not correct for Linux
There is a whole specification for where certain types of programs installed in certain types of ways are supposed to put their unit files, in Linux. The reason being, locations "closer" to the user and their profile that are installed manually by the user should have precedence over locations for the entire system or that were installed by a package manager. See https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#Unit%20File%20Load%20Path, Table 2.
You have chosen one of the highest priority locations, which should be reserved for me as a user. It seems that, for package installs on Debian, RedHat, etc. (I can't speak to NixOS), you should be installing the user unit into `/usr/lib/systemd/user`. It won't change anything about the activation command (`systemctl --user enable --now openlogi-agent.service`). But it will allow users the proper control on Linux.
Finally, while filling out this bug report, the template says "Linux and Windows are still stubs." But that does not seem to be true, there seems to be pretty full support for Linux and Windows now.
### Steps to reproduce
1. Download Debian release
2. Run the command `sudo dpkg -i openlogi_*.deb`
3. Receive error message `dpkg: error: cannot access archive 'openlogi_*.deb': No such file or directory`
4. Change command to `sudo dpkg -i openlogi-*.deb`
5. Deb package is installed
### Diagnostics report
```markdown
```
### `openlogi list` output
```text
```
### Logs
```shell
```
### macOS permissions (if applicable)
- [ ] OpenLogi has **Accessibility** permission (needed to remap buttons via the event tap).
- [ ] OpenLogi has **Input Monitoring** permission (needed for Bluetooth-direct devices and capture).
Contributor guide
No contributing guide indexed for this repository
Research direction
Review the Linux installation sections in README, openlogi.org/docs/getting-started/installation#linux, and docs/INSTALL-linux.md#autostart-launch-at-login. Check the Debian package filename and the documented systemd user-unit location against the install behavior, then verify the corrected dpkg command, package installation, and user service activation on Linux.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- debian, linux, rust
- Domain
- devops, documentation, operating-systems, release
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100