As ntp comaintainer, I have so far resisted adding the time-daemon provides because I find that the interface and the purpose is underspecified.
For example, nothing specifies whether a "time-daemon" should set the true time, or a synchronized time, or just a reasonable time. There is nothing that a package depending on time-daemon could rely on. Of course, many multi-host software systems like synchronized clocks, but a package dependency can't express that anyway. (And a default ntp installation in fact does not really provide synchronized clocks.) The other use case is package conflicts. Offhand, it makes a great deal of sense to have only one program messing with the system time. But that doesn't mean that all these time-related packages need to conflict with each other. For example, both ntp and ntpdate (or chrony and ntpdate) can be used together. But they are both time-setting programs on their own right. (Admittedly, ntpdate is not a "daemon".) It's also possible that people only want to use the user-space tools of ntp but use a different daemon. The access to the clock should be controlled in a different way. I consider this to be a different situation than mail-transport-agent, which actually do conflict because they all provide /usr/sbin/sendmail. So while I don't have a strong opinion about the removal of time-daemon, I'd need to see a clearer definition before I can put it into use. (The same really applies to many other virtual packages.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
