Comment by jcgl
That seems like a fair point about the documentation! As far as I can see, you're right.
That seems like a fair point about the documentation! As far as I can see, you're right.
I don't personally find it as disturbing as you do, I think. Which isn't to say that I don't think it should be fixed, etc. etc.
I'm sure the project would accept a documentation patch to amend this discrepancy. At the end of the day (despite what some people on the internet might like to allege), systemd is a free software project that, despite having (more or less) a BIFL, is ultimately a relatively bazaar-like project.
Though since these targets and unit properties are very core to systemd-the-service manager, I do think that this is a bigger documentation oversight than most.
The disturbing part isn't the bug in time-sync.target or documentation, the disturbing part is how casually he brushes the issue away.
To me this is a huge red flag for a senior contributer to a core systems component, signalling some fundamental lack of understanding or imagination.
I very much disagree with not fixing time-sync.target, but if he had instead written a well-reasoned explanation for why time-sync.target should not propagate failed states and flagging it as a documentation bug, then that's something I'd respect and would be fine with. Or, even better IMHO, he'd fix time-sync.target and state that users who wants to boot regardless should use Wants instead.
So that's why I find his statements disturbing.
If he really don't want targets to deliver failed/success guarantees, then they've massively miscommunicated in their documentation. That in my book is a huge deal.
In either case the issue should in no circumstance be casually dismissed as not-a-bug without further action.