I suspect many Linux users would expect to manage a roborev installation through their package manager. It's not too difficult to build .deb and .rpm packages using the nfpm project, which could then be made part of the GitHub release artifacts. They could even be used by default for supported distros in the install script.
Packages are also a logical way to distribute systemd unit files, which we now have pretty nice support for.
An annoying downside of this is that the existing roborev update subcommand wouldn't work without escalated privileges and would kind of break the package management model. Maybe there could be a build-time flag to disable it?
I notice that there's already an AUR package for Arch users, too.
I suspect many Linux users would expect to manage a
roborevinstallation through their package manager. It's not too difficult to build.deband.rpmpackages using thenfpmproject, which could then be made part of the GitHub release artifacts. They could even be used by default for supported distros in the install script.Packages are also a logical way to distribute systemd unit files, which we now have pretty nice support for.
An annoying downside of this is that the existing
roborev updatesubcommand wouldn't work without escalated privileges and would kind of break the package management model. Maybe there could be a build-time flag to disable it?I notice that there's already an AUR package for Arch users, too.