Hello Paul Wise. Thanks for your bug report.
On Mon, Jan 11, 2016 at 08:43:41PM +0800, Paul Wise wrote: > Package: kbd > Version: 2.0.3-2 > Severity: wishlist > File: /usr/share/doc/kbd/examples/vcstime.service > > It would be nice to move vcstime.service to the standard systemd > directory (and enable all the hardening) but disabled by default so > that it is just a systemctl enable/start away from working on boot. > There isn't any downside to this as far as I can tell. I was debating with myself over shipping it disabled or as an example. Here are the reasons I decided for example: * shipping only a service is not policy compliant and does not work (cf. #747851), so I'd have to write and maintain an init script as well. (Contributions welcome, preferably via getting both init script/service merged upstream.) * From my quick look at vcstime.c it doesn't give me the impression to be a very efficient program or otherwise of quality I would recommend people to use/enable. * The vcstime is shipped by upstream under "contrib" which I'm not sure what it means but doesn't give me the feeling it's not fully supported by upstream. The contrib tools are not even built by a regular upstream build. * The vcstime utility really has nothing to do with the main functionality of the kbd package (which I think is quite core os stuff), maybe we should consider splitting core kbd parts from contrib stuff.... which means we would have to move conffiles between packages which AFAIK is still an unsolved problem. * ... In short, I'm too lazy and don't want to commit to support vcstime. For now I'm of the opinion that anyone who really wants to enable vcstime should atleast get to ask themselves "maybe there was a reason for shipping this as an example so I have to copy it myself to /etc/systemd/system before enabling it?". I think this is easy enough that enabling it isn't annoyingly hard if you really want it. The distinction between shipped-disabled and example units is the best way to signal "supported" vs. "you're-welcome-but-do-expect-you-have-to-maintain-it-yourself". Regards, Andreas Henriksson
