Hi,
However, development for ntp.org is slow, upstream still using BitKeeper
is cumbersome, and even the testsuite needs to be fixes on some
architectures for new releases. Both ntpsec and chrony are (from my POV)
the better alternatives now. To a point where I would rather use chrony
for new deployments, but I'm shying away from not using my own work
anymore for the lack of real-life testing.
I could just step down as a maintainer/uploader and have the ntp
packaging bitrot, but this would be a large disservice to our users
(unless someone else continues to maintain it). I think another option
would be to migrate to one of the alternatives for Bookworm.
This has sparked even less controversy than I feared, so let's use the
momentum.
AFAICT other than systemd-timesyncd being installed by default we don't
have a "default" NTP daemon in Debian. There are a few that depend on at
least one implementation (on my Bullseye workstation)
Package: bwctl-server
Depends: ntp
Package: lava
Depends: ntp | ntpdate | chrony
Package: openstack-cloud-services
Depends: ntp
Package: openstack-compute-node
Depends: ntp
Package: progress-linux-host
Depends: ntp
Package: freeipa-server
Depends: chrony
Package: ceph-base
Recommends: chrony | time-daemon | ntp
Package: radioclk
Recommends: ntp (>= 1:4.2.2+dfsg-1) | ntpsec | chrony
Package: debci
Recommends: ntp | time-daemon
Package: openafs-fileserver
Recommends: ntp | time-daemon
Package: slony1-2-bin
Recommends: ntp | time-daemon
So we should most probably decide on a "default" and have all of them
changed to $newdefault | time-daemon
As default both ntpsec and chrony are challengers. Both support NTS.
Both appear to be active upstream and in Debian. Chrony has a higher
popcon (possibly due to things like the default installation in the
cloud images) and is default in Fedora/RHEL land. Feedback on this list
also seems to favour chrony. My personal preference would be slightly
towards chrony as well.
And then there is the migration from src:ntp. I think only ntpsec would
be an option here, which should be 99% compatible with the existing
configuration file. ntpsec even takes over the old ntp configuration
when it replaces ntp already. I guess the conffile prompt would be fine
during a dist-upgrade.
For the actual migration, src:ntp currently builds 4 binary packages
ntp
ntp-doc
ntpdate
sntp
ntp-doc could be an easy transitional package
sntp could depend on on the ntpdig package from #1003966, but it would
probably need to carry a compatibility symlink
ntpdate and ntp could be transitional packages on the ntpsec
counterparts as well, but since ntpsec/ntpsec-ntpdate has
Conflicts/Replaces on the src:ntp binary packages it needs coordination.
For this reason building the transitional binaries from src:ntpsec would
probably be easier.
Bernhard
