On 01/28/2017 07:55 PM, Quentin Bourgeois wrote:
As the daemon is expected to talk with an USB device I included an udev rules that should match it and allow logged user interaction. In addition, the project does not include any systemd service file. The daemon is expected to run for every user session so I use systemd user instance. This service file is now very basic I will first try to make it upstream, so every distribution could benefit from this eventually. I guess that a lot are using systemd now.
Yes, please do that. If upstream won't do so however, it is okay to bundle a service file with the PKGBUILD. Upstream should also, ideally, install a udev rule themselves. For some reason, their README explicitly tells Ubuntu and Arch users to create *different* udev rules by hand, using `echo ... | sudo tee`. Which is weird for several reasons.
While creating the systemd file I was wonderering how would be the guideline in a case that an upstream systemd service file won't match (for any reason) Arch Linux policy (let say applying it will break the package functionality in Arch) would the good way to fix it in the first would be to create in the PKGBUILD a systemd drop-ins?
I'm not sure what you even mean by this. How would a systemd unit break its own functionality, and if so, why wouldn't that be a cause for concern upstream? What Arch Linux policy would it violate anyway?
Regarding udev, after installing my rule I decided to force reloading the rules files but not replaying event (only print a message to warn the user). My view is that the later would only be needed for people that already plugged the device before installing the package.
Take a look at the (many) packages that own a file in /usr/lib/udev/rules.d/ and try to see how many of them include an install script explicitly reloading the rules. (Hint: None of them.) There is a reason for this, udev is already pretty smart. As for the message, surely that is rather obvious already? install scripts are meant for situations where simply installing the package isn't enough to actually make things work, or *vitally critical information is likely to elude the user* unless you bug them about it in a post-install message. Telling the user that an intuitive aspect of hardware device control applies here too, smells like over-mothering handholding to me.
Even with the i686 phase out, the tools seems to work great with this architecture, so I included it too.
Given that i686 isn't going to be dropped at all for months yet, and even then stands a good chance of being kept alive as a second-tier, officially-supported arch, I wouldn't be so hasty to drop it anyway. :)
Finally, the release name[3] currently include "beta" (like v0.5.2-beta) does I have to put this into the pkgver or leave as 0.5.2?
Are they using the word "beta" to mean "we haven't reached the 1.0 milestone yet, and/or this project has no polish and may eat your homework, #include <stddisclaimer.h>" or "we are currently testing something out that may not work, please check out our stable branch"? That is how I would look at it. -- Eli Schwartz