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.
-- Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
