#1057966 ntpsec-ntpdate not fully compatible with ntpdate, causes adjtimex --host breakage

Package:
ntpsec-ntpdate
Source:
ntpsec-ntpdate
Description:
client for setting system time from NTP servers
Submitter:
E Harris
Date:
2023-12-11 05:06:03 UTC
Severity:
normal
#1057966#5
Date:
2023-12-11 01:55:08 UTC
From:
To:
When attempting to use adjtimex --host command, it fails due to current
ntpdate not being fully compatible with previous ntpdate package.

# adjtimex --host 66.118.228.14
ntpdate: -p is no longer supported.
ntpdig: querying 66.118.228.14 (66.118.228.14)
cannot understand ntpdate output

#1057966#10
Date:
2023-12-11 04:53:32 UTC
From:
To:
 From ntpdate (the wrapper):
# Known bugs:
# * The -e and -p options of ntpdate are not yet implemented.
# * ntpdate took 4 samples and chose the best (shortest trip time).
#   This takes the first.

I suppose there are maybe 4 options here:

A) Do nothing.
B) Change adjtimex to not pass -p.
C) Change ntpdate to accept -p but ignore it. Currently, it gives an
    error message of "-p is no longer supported." as you saw.
D) Have the wrapper repeatedly calling ntpdig and... then what?
E) Actually implement support for this in ntpdig and pass the flag
    through.

Obviously A is the null option, and we are looking for something better.

I don't love C, as that silently eats an option rather than being
explicit that it doesn't do anything.

D is terrible, so I'm going to veto that one.

I'm not personally interested in implementing E, but I don't see why I'd
reject a patch if someone else was interested.


Regarding B, it turns out that -p4 is being _added_ in adjtimex as a
Debian patch: debian/patches/11-Fix-ntpdate-command.patch

That references this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987625

That is for the ntp ntpdate, not ntpsec-ntpdate.

@rosh, what do you think? Could you just remove
11-Fix-ntpdate-command.patch? That would fix adjtimex.