Comment 3 for bug 1764357

Several insights on all of this:

"who wins":
install ntp, chrony or openntp (can only be one so take chrony) - reboot - who wins?
-> Seems to work always to be chrony, but why.
-> also matches some tests by waveform
I started a discussion with systemd upstream if there are guarantees.
On IRC it was suggested that it might just be alphanumeric.
I made some tests to check the influence of other things like enabling in different orders.
But it stuck to alphanumeric wins.
In our case that is great as every NTP service name is >> systemd-timesyncd.
While opening a systemd github issue to be sure I found that it is actually random.
And it seems there is no way ton control it.
Until that exists we can re-arrange our POV:
- this is only a "problem between systemd-timesyncd and the servers"
- the old condition to not start when installed would avoid that completely
- a perfect solution (that detects not "installed" but running) could wait until upstream solves it

"masking":
I found that the "Masking" of chrony/ntp services is actually a conflicts in packaging- that is good (because it is the right thing to do).
That means that one who installs one of the NTP servers is removing the others (that is just right so). The packages solve that via a virtual package to not have to list all of each other.
openntp and chrony and ntpsec provide "time-daemon"
They all conflict with time-daemon, so only one of them can be installed even not listing all of them.
The only outlier is ntp (did I mentione we went away from it), but for that all of them explicitly conflict with ntp as well.

"Severity" -> low/med:
Of the above of case 1-3 were worse on Xenial
Xenial => systemd-timesyncd
Xenial - install ntpd => ntpd AND systemd-timesyncd running
Xenial - then after reboot, only ntpd
This is due to ntp being a sysV script in Xenial and has no way to express the conflicts.
Due to that both run, only after a reboot the condition in the old systemd-timesyncd would prevent it from starting.
But it would even have done so if ntp was only installed, but not running.
And while broken we never had bugs about the above in the last two years.
And the conflicts behavior is better than that at least.

Summarizing what we really need now:
1. better completeness of those services conflicting with each other (simple add to their .service files) - one "direction" of conflicts is enough so fix those in main (chrony in that case)
2. determinism (which starts if multiple are installed)
   For now re-vive what https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873185 dropped
3. after removal of the NTP daemons we'd want systemd-timesyncd to pick up again immediately (without a reboot)