Pulsar Mouse Linux, ein inoffizielles Konfigurationswerkzeug für Pulsar-Gaming-Mäuse unter Linux, wurde in Version v0.1.10 veröffentlicht - kurz darauf folgte Version 0.1.11 mit einem wichtigen Fix für das .rpm-Paket.
Noch am selben Tag wie Version 0.1.9, die neue Tasten der Pulsar X2A Wireless freigeschaltet hatte, folgt ein reines Packaging-Update: Die .deb- und .rpm-Pakete installieren pulsar-mouse und pulsar-mouse-gui nun nach /usr/bin statt nach /usr/local/bin. Beim Upgrade werden die alten Dateien automatisch entfernt, install.sh bleibt bei /usr/local.
In Version 0.1.11 wurde ein Fehler behoben, durch den jedes bisher veröffentlichte .rpm-Paket (mindestens 0.1.8 bis 0.1.10) das Python-Paket nach /pulsar_mouse im Wurzelverzeichnis statt nach site-packages installiert hat - das .rpm war dadurch nie funktionsfähig. Beide Paket-Builds prüfen ihr Layout nun selbst.
Änderungen 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
Änderungen 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
Quelle: GitHub