I have a system that runs chrony to synchronise it's clock.  But I'd like
to be able to run ntpq on that system to query other systems on the
network that are running ntpd.  This is difficult because /usr/bin/ntpq is
in the ntpsec package, which conflicts with chrony, so I can only use ntpq
if I also change what I'm using to synchronise my own system's clock.

I think it would be useful if ntpq were in a separate package from ntpd,
so that I could use it without having to remove chrony.

If I do this, I think these should be split out, e.g. into ntpsec-tools:
- ntpmon
- ntptrace
- ntpq

These are questionable, but I lean towards including them:
- ntpkeygen
- ntpleapfetch
   (largely irrelevant on Debian, tzdata ships the leap file)

but not:
- ntptime (which uses a kernel interface)
- ntpwait (its use case being specific to ntpd)

Off the top of my head, it feels like ntpsec would only need to
Recommend/Suggests ntpsec-tools, not Depends. That should probably be a
multi-step process, though. That is, for forky, ntpsec Depends
ntpsec-tools. Then for forky+1, it is reduced to a Recommends/Suggests.
That way, current users would get ntpsec-tools and not lose any of the
tools that they have currently installed.

Currently, the ntpsec-ntpdate package is somewhat double-duty. It ships
ntpdig/ntpdate/ntpdate-debian, at least some of which could be useful
standalone. But it also ships the stuff to use ntpdate in the
"alternate" mode of "poll for time periodically" (rather than running ntpd).

Arguably, ntpdig/ntpdate (but probably not ntpdate-debian) could be
moved to ntpsec-tools. The upside of that is that ntpsec-tools would get
you ntpdig, which is a useful tool. The downside is that people doing
that "alternate" method of time syncing would pull in a handful of
unnecessary tools.