Hm... thanks for reporting!
That said, what's the problem here, besides the piuparts message?. It is
perfectly possible (actually, recommended) to run lircd as a regular
user. When doing so, the output socket is by default created as
/run/lirc/lircd which will fail unless the directory is 777.
This is really following the systemd tmpfiles.d semantics, where the
/var/run directories are created py the package but not owned by it. I'm
still new to Debian, do I miss something here?
BTW, I tried the tmpfiles.d support in the dh_ files (details lost in L2
cache), but at that point it was buggy. Yes, I should have filed a bug,
but I didn't. Shame on me.
In the long run, the proper way would be to change the package to run
as a regular user and use group permission to access the /var/run
directory. The short-time "fix" would be to make /run/lircd 755,
breaking users running lircd (but not the service). I'm not really happy
to apply such a patch... thoughts?
