This is complete and utter non-sense...

I mean, if you install NTP server software, why the hell should a UI like GNOME cover that? Will you create a UI for enabling Apache next?

The boolean is for enabling a simple NTP client, that's all. 

Honestly, if you think that GNOME should control server software, then talk to them, but don't fuck up our APIs with overriding it. In the newer systemd versions the unit enablement and disablement APIs support polkit, so there's no need at all to fiddle with the NTP prop anymore.  Just make GNOME control your NTP server of choice directly...

Well, timesyncd is not really ready as an NTP client for F22. So they want to be able to enable whatever ntp client is installed.

Yes, we want to be able to select the default NTP client at the distribution/product level and not break GNOME control and other applications using the timedated API.

This is not about NTP servers, I'm not sure why Lennart keeps bringing that up.

If someone thinks timesyncd should be the default client, submit a change proposal and we can discuss the advantages and disadvantages it would have against the current default.

(In reply to Miroslav Lichvar from comment #3)
> 
> If someone thinks timesyncd should be the default client, submit a change
> proposal and we can discuss the advantages and disadvantages it would have
> against the current default.

There is no such thing as system wide default anymore after the move to "products" and people need to start realizing that fact.

For example baseWG and workstation WG might want to use timesyncd as their client while cloudWG and serverWG might want to use NTP. 

As such arguably each "WG" now needs to carry it's own preset file for their stuff.

Sure, different products can have different NTP clients installed by default and with timedatex we can now do that without breaking applications using the timedated API.

(In reply to Miroslav Lichvar from comment #5)
> Sure, different products can have different NTP clients installed by default
> and with timedatex we can now do that without breaking applications using
> the timedated API.

The only way how ( due to units having to be conflicting with each other ) is for those that dont want timedated+timesyncd build systemd without timedated and provide an alternative implementation of its D-Bus interface from F22 and onwards so obviously the WG that chooses to do that will need to maintain it's own version of systemd without that compiled in so the proper course of action here is... 

For chrony to drop  /usr/lib/systemd/ntp-units.d/50-chronyd.list

And add

Conflicts=systemd-timesyncd + all others ( including timedatex )

For NTP to drop /usr/lib/systemd/ntp-units.d/60-ntpd.list

Conflicts=systemd-timesyncd + all others ( including timedatex )

For $EVERYTHING_BEING_SHIPPED to drop

/usr/lib/systemd/ntp-units.d/$FOO-LIST

Conflicts=systemd-timesyncd + all others ( including timedatex )

gnome-control-center/xfce4-settings etc. drop the support for /usr/lib/systemd/ntp-units.d from their code.

(In reply to Jóhann B. Guðmundsson from comment #6)
> The only way how ( due to units having to be conflicting with each other )
> is for those that dont want timedated+timesyncd build systemd without
> timedated and provide an alternative implementation of its D-Bus interface
> from F22 and onwards so obviously the WG that chooses to do that will need
> to maintain it's own version of systemd without that compiled in so the
> proper course of action here is... 

I don't follow. If timedatex is installed (as a dependency of chrony/ntp packages) and the timedatex service is enabled (from preset as requested in this bug), the timedated applications talk to timedatex. If not installed or not enabled, they talk to systemd-timedated as expected.

To avoid wasting disk space it would of course be better if timesyncd, timedated and other stuf had their own systemd subpackages, but it's not necessary.

(In reply to Miroslav Lichvar from comment #7)
> (In reply to Jóhann B. Guðmundsson from comment #6)
> > The only way how ( due to units having to be conflicting with each other )
> > is for those that dont want timedated+timesyncd build systemd without
> > timedated and provide an alternative implementation of its D-Bus interface
> > from F22 and onwards so obviously the WG that chooses to do that will need
> > to maintain it's own version of systemd without that compiled in so the
> > proper course of action here is... 
> 
> I don't follow. If timedatex is installed (as a dependency of chrony/ntp
> packages) and the timedatex service is enabled (from preset as requested in
> this bug), the timedated applications talk to timedatex. If not installed or
> not enabled, they talk to systemd-timedated as expected.

timedated only manages timesyncd if you want to use something else then build systemd without timedated and provide an alternative implementation of its D-Bus interface and carry a patch or convince upstream to use that.

Dont re-use or introduce anything under the systemd namespace ( particularly in this case /etc/systemd/ntp-units.d, /usr/lib/systemd/ntp-units.d ). 

I'm pretty sure no one here ( and upstream ) wants to start dealing with any fallout bugs from "copy" implementations of components since it *will* double the work on everybody ( is it timesyncd or timedatex etc )

Arguably systemd should hard crash if it detects some hacks like that.

(In reply to Jóhann B. Guðmundsson from comment #8)
> Dont re-use or introduce anything under the systemd namespace ( particularly
> in this case /etc/systemd/ntp-units.d, /usr/lib/systemd/ntp-units.d ). 

The systemd package no longer owns that directory, but I can see your point. I think it wouldn't be a big problem to move the directory somewhere else.

> I'm pretty sure no one here ( and upstream ) wants to start dealing with any
> fallout bugs from "copy" implementations of components since it *will*
> double the work on everybody ( is it timesyncd or timedatex etc )

Agreed. If only systemd upstream considered that before they dropped the NTP selection code.

(In reply to Miroslav Lichvar from comment #9)
> (In reply to Jóhann B. Guðmundsson from comment #8)
> > Dont re-use or introduce anything under the systemd namespace ( particularly
> > in this case /etc/systemd/ntp-units.d, /usr/lib/systemd/ntp-units.d ). 
> 
> The systemd package no longer owns that directory, but I can see your point.
> I think it wouldn't be a big problem to move the directory somewhere else.

Upstreams would have re-factor their code to support fork of timedated and it's dbus implementation ( which should be implemented under another name space as in org.freedesktop.timedatex in your case )

> > I'm pretty sure no one here ( and upstream ) wants to start dealing with any
> > fallout bugs from "copy" implementations of components since it *will*
> > double the work on everybody ( is it timesyncd or timedatex etc )
> 
> Agreed. If only systemd upstream considered that before they dropped the NTP
> selection code.

It serves no purpose to support other solution et all if systemd is being used ( and since what Gnome 3.4, it depends on systemd dbus api's not forks of them along with XFCE and soon KDE etc ) so wide variety of usptreams support just that or the option to build without systemd encase you want to use something else.
 
Just out of curiosity what was the workstation's WG along with the KDE/XFCE/LXDE community's take on this since I believe the upstream Gnome camp recommendation was to remove chrony/ntp upon upgrades and dont deploy them on fresh Gnome installs ( although they ensured nothing would be broken upon this transition ).

(In reply to Zbigniew Jędrzejewski-Szmek from comment #2)
> Well, timesyncd is not really ready as an NTP client for F22. So they want
> to be able to enable whatever ntp client is installed.

What's missing from timesyncd being ready as an ntp client for F22 and onwards?

(In reply to Jóhann B. Guðmundsson from comment #11)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #2)
> > Well, timesyncd is not really ready as an NTP client for F22. So they want
> > to be able to enable whatever ntp client is installed.
> 
> What's missing from timesyncd being ready as an ntp client for F22 and
> onwards?

It doesn't cover all the cases yet:
- It tends to inexplicably crash on arm every once in a while.
- It does not implement exponential fallback of queries in all cases.
- I'm not sure how it functions when systmed-networkd is not running.
And most important, it hasn't been widely tested yet. 

(In reply to Miroslav Lichvar from comment #3)
> If someone thinks timesyncd should be the default client, submit a change
> proposal and we can discuss the advantages and disadvantages it would have
> against the current default.
Yes, I think this is the right thing to do for the distribution as a whole.
systemd-timesyncd is not far from being ready, so it is possible that the
proposal would go through, but I think we should go through this public discussion
before we enable it widely. So far nobody has stepped up to do that.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #12)
> (In reply to Jóhann B. Guðmundsson from comment #11)
> > (In reply to Zbigniew Jędrzejewski-Szmek from comment #2)
> > > Well, timesyncd is not really ready as an NTP client for F22. So they want
> > > to be able to enable whatever ntp client is installed.
> > 
> > What's missing from timesyncd being ready as an ntp client for F22 and
> > onwards?
> 
> It doesn't cover all the cases yet:
> - It tends to inexplicably crash on arm every once in a while.
> - It does not implement exponential fallback of queries in all cases.
> - I'm not sure how it functions when systmed-networkd is not running.
> And most important, it hasn't been widely tested yet. 

Regardless of that it does cover upstream that rely on it and it's no assurance that timedate implementations in wide variety of upstreams support /usr/lib/systemd/ntp-units.d/foo.list(s) ( and if they do no assurance for how long ) so how do you propose that being solved since his solution does not do that. ( it's just implemented on the hope it does )

The proposed solution currently works with ntp and chrony. That should be sufficient for now.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #14)
> The proposed solution currently works with ntp and chrony. That should be
> sufficient for now.

I somehow doubt that you have looked upstream *DE's where they are using timedate dbus API to see if the proposed solution still works there, in all of them and with multiple time clients/servers. 

And the current implementation of ntp and chrony running and being managed via systemctl works just fine so if the intent is to have timedated the place to control multiple NTP client/servers, in desktop here downstream it's better to drop timedatex and revert the relevant commit instead of having half assed fork floating around in the distribution doing the same and potentially break applications in DE's in the process. ( I'm pretty sure this fork has received less testing time in all the DE's than timedate+timesyncd itself )

But hey that's just me so you if are confident that timedatex is the correct way forward and the best mean to handle this by all means and let's see how well that pans out in the long run...

(In reply to Jóhann B. Guðmundsson from comment #15)
> And the current implementation of ntp and chrony running and being managed
> via systemctl works just fine so if the intent is to have timedated the
> place to control multiple NTP client/servers, in desktop here downstream
> it's better to drop timedatex and revert the relevant commit
That's what I did in F21.
Upstream, and in F22, the revert was not added.

I think the revert is good (I did it myself after all), but it is a divergence from upstream. As you can see from comment #c1 there's strong upstream opposition.

(In reply to Jóhann B. Guðmundsson from comment #11)
> What's missing from timesyncd being ready as an ntp client for F22 and
> onwards?

Some of the problems I'm aware of:
- not a full NTP client (reliability)
- poor clock control (jittery/congested/intermittent networks, virtual machines)
- no integration with NetworkManager (missing servers from DHCP)

To be considered as a replacement for chrony, I think it would need to be comparable in the basic features and do something better, otherwise I don't see the benefit for the distribution or products. Also, I think the upstream should be able to catch serious bugs like frequent polling before making new release.

Anyway, this bug can be closed as systemd-218-5 was built in rawhide. Thanks!