[Devel] Proposal: switch from ntp to ntpsec in Apertis

[Andrej Shadura]

Hi all,

In short, Debian is considering removing ntp package and switching to 
ntpsec which is a drop-in replacement. In Apertis, we already use 
systemd-timesyncd as a default ntp client, and ntp is as far as I can 
see only a dependency of some packages. Namely, fake-hwclock has ntp as 
a hard dependency, but not because it requires strictly ntp, but because 
at the time the dependency was added, there was no other viable 
alternative. However, it remains to be seen how much fake-hwclock itself 
is necessary, as it seems systemd-timesyncd already provides a replacement:

 From 
https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html:

> systemd-timesyncd is a system service that may be used to synchronize
> the local system clock with a remote Network Time Protocol (NTP)
> server. It also saves the local time to disk every time the clock has
> been synchronized and uses this to possibly advance the system realtime
> clock on subsequent reboots to ensure it (roughly) monotonically advances
> even if the system lacks a battery-buffered RTC chip.

-------- Forwarded Message --------
Subject: Re: The future of src:ntp
Resent-Date: Wed, 19 Jan 2022 03:20:23 +0000 (UTC)
Resent-From: debian-devel at lists.debian.org
Date: Tue, 18 Jan 2022 21:19:27 -0600
From: Richard Laager <rlaager at debian.org>
To: debian-devel at lists.debian.org

[I'm the Debian ntpsec maintainer.]

On 1/18/22 11:21 AM, Paride Legovini wrote:
  > I'd prefer making ntp a dummy package depending on ntpsec rather than
  > having src:ntpsec takeover bin:ntp.

If I understand correctly, you're suggesting src:ntp builds bin:ntp that 
is a dummy package which depends on ntpsec?

Another option would be to have src:ntpsec build the bin:ntp dummy 
package and remove src:ntp entirely.

Either seems fine to me. I don't have a strong preference. I can 
implement whatever is necessary on the ntpsec side.

And for either option, probably likewise ntp-doc -> ntpsec-doc, ntpdate 
-> ntpsec-ntpdate, and if I broke out ntpdig as suggested in bug 
#1003966, sntp -> ntpsec-ntpdig.

There are some differences. For example, ntp stores its configuration 
file at /etc/ntp.conf while ntpsec uses /etc/ntpsec/ntp.conf. [1] But 
bin:ntpsec's postinst already handles that transition.

On 1/18/22 5:03 PM, Paride Legovini wrote:
  > bin:ntp has always been a specific NTP implementation, I think
  > it's OK if it's replaced by an almost compatible fork, less OK if a
  > completely different implementation is brought in instead.

I'm biased here, but I agree. I think it makes the most sense to 
transition existing ntp installs to ntpsec, not chrony, as ntpsec is a 
drop-in replacement with a shared code history. This is my position even 
if we think that chrony should be the default for new installs. On that 
topic, I think the current default of systemd-timesyncd is fine.

[1] When I was first packaging ntpsec, I was going to have it share as 
many paths, service names, etc. with ntp (as upstream NTPsec does). But 
this lead to issues with certain tooling (e.g. around init scripts) and 
ultimately I decided it was better to use a different namespace. This 
does mean that Debian ntpsec is patched and diverges a bit from upstream 
NTPsec.

-- 
Richard