[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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature