Pulsar Mouse Linux, an unofficial configuration tool for Pulsar gaming mice on Linux, has been released in version v0.1.10 - shortly after, version 0.1.11 followed with an important fix for the .rpm package.
On the same day as version 0.1.9, which unlocked additional buttons on the Pulsar X2A Wireless, this is a pure packaging update: the .deb and .rpm packages now install pulsar-mouse and pulsar-mouse-gui into /usr/bin instead of /usr/local/bin. Old files are removed automatically on upgrade, while install.sh keeps using /usr/local.
Version 0.1.11 fixes a bug where every .rpm published so far (at least 0.1.8 through 0.1.10) installed the Python package into /pulsar_mouse at the filesystem root instead of site-packages - so the .rpm never actually worked. Both package builds now verify their own layout.
Changes in version 0.1.10:
Package the entry points into /usr/bin, not /usr/local/bin
Both the .deb and the .rpm installed pulsar-mouse and pulsar-mouse-gui into /usr/local/bin. That directory belongs to the local administrator - Debian policy says a package must not touch it, and the FHS says the same - so the package was claiming paths that are not its to claim, and dpkg -S reported it owning files under a tree meant to be package-free. It also sat ahead of /usr/bin on the default PATH, so the packaged scripts silently shadowed anything installed there by hand.
install.sh keeps its PREFIX=/usr/local default: that one is run by the admin directly, which is exactly what /usr/local is for. The AppImage runs python3 -m pulsar_mouse.cli and the desktop entry execs by name, so neither cared where the scripts lived.
Upgrades clean themselves up: the files are owned by the same package name, so dpkg removes the /usr/local/bin copies as part of unpacking a version that no longer ships them. Verified on a machine running 0.1.9 installed the old way - after upgrading with a package built from this recipe, the old paths are gone, /usr/bin holds both scripts, dpkg -S agrees, and the CLI still talks to the mouse.
Full Changelog: https://github.com/packerlschupfer/pulsar-mouse-linux/compare/v0.1.9...v0.1.10
Changes in version 0.1.11:
Fix the .rpm installing the Python package at /, and assert both layouts
Every .rpm this project has published - 0.1.8, 0.1.9, 0.1.10 all verified - put the Python package in /pulsar_mouse at the filesystem root instead of site-packages. The entry points could not import the package installed beside them, so the .rpm has never worked, and it scattered files across /. The .rpm has no downloads on any release, which is presumably why nobody said so.
The cause: %python3_sitelib is defined as a shell expansion that runs python3, and the build step installed rpm-build and python3-rpm-macros but never python3 itself. With no interpreter in the image the macro expanded to an empty string, in silence - %{buildroot}%{python3_sitelib}/pulsar_mouse became %{buildroot}/pulsar_mouse, and the matching %files entry agreed with it, so rpmbuild had nothing to complain about.
python3-devel is now installed (it is what provides these macros on Fedora, and it pulls the interpreter they call), the spec defines the macro itself if the builder hasn’t, and both package builds now assert their own layout: the package must be in site/dist-packages, the entry points must be in /usr/bin, and nothing may land in /usr/local. Verified by building in a Fedora container and by re-breaking the path on purpose to watch the guard fail the build.
Full Changelog: https://github.com/packerlschupfer/pulsar-mouse-linux/compare/v0.1.10...v0.1.11
Source: GitHub