[pkg-ntp-maintainers] Bug#892966: Bug#892965: Bug#892966: ntpsec-ntpdate: unconditionally removes /var/lib/ntpdate on purge, even if ntpdate is installed

[Richard Laager]

[ Removing the bug addresses, and adding pkg-ntp-maintainers. ]

In general, I think my priorities in this space are:
1) Don't break the ntp packages.
2) Provide a great experience with ntpsec.
3) Provide for as seamless a transition as practical from ntp to ntpsec.
4) Provide for as seamless a transition as practical from ntpsec to ntp.

I'm very willing to coordinate, and in the absence of coordination, my
intention is to defer to the ntp packages whenever reasonably practical.

Getting back to specifics...

We're still both using /run/ntpdate.dhcp, because the ntpsec-ntpdate
scripts are currently straight copies of the ntpdate scripts. But that
should be fine, since ntpsec-ntpdate Conflicts with ntpdate and thus
they cannot be simultaneously in use. Likewise for /etc/default/ntpdate,
where I'm installing the same contents as you.

If you were open to supporting it, we could potentially kill off
ntpsec-ntpdate in favor of a single ntpdate Debian package which is
compatible with both NTP and NTPsec.

However, something to keep in mind is our upstreams have diverged a bit.
Your upstream is moving towards an "sntp" utility, while mine has
renamed that "ntpdig". My upstream ntpdig has also been completely
re-written from C to Python. I haven't closely compared the options for
compatibility, though they should be.

Right now, I'm invoking ntpdig via NTPsec's ntpdate shell script
wrapper, which translates options as necessary. If we diverge in any
significant way, I'll likely have to or want to abandon compatibility
with /etc/default/ntpdate (specifically due to NTPOPTIONS). At that
point, it seems obvious that I should re-work the scripts to use native
ntpdig options rather than the ntpdate options.

-- 
Richard