On Tue, Feb 17, 2015 at 12:52:20AM +0100, Michael Biebl wrote: > Am 17.02.2015 um 00:27 schrieb Josh Triplett: > > On Mon, 16 Feb 2015 16:41:21 +0100 Martin Pitt <mp...@debian.org> wrote: > >> For jessie+1/experimental onward, we'll fix this properly by enabling > >> timesyncd by default. It won't start if ntp or similar are installed. > >> This will make sure that the hw clock will be updated often enough, > >> and we won't poke false data into it: > >> > >> > >> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimental&id=929bece5326 > > > > Using ConditionFileIsExecutable on specific NTP daemons seems odd here. > > Doesn't systemd already have a mechanism for choosing from multiple > > alternative implementations of a given feature, automatically running > > only one of them? If not, perhaps it should; that same mechanism would > > then work for display managers, web servers, etc. > > Sort of. The plan here is, that the individual ntp implementations ship > a native systemd unit file, which has > Conflicts=systemd-timesyncd.service [1] > > This will make sure, that if e.g. ntp is installed and enabled, ntp will > be used instead of systemd-timesyncd. > > None of the ntp implementations currently ship such a native unit file > though, that's why we decided to add such a Condition to the > systemd-timesyncd.service unit file for the time being. > > There were concerns that adding this Conflicts to every time > synchronization service is a questionable approach [2].
Seems like systemd could take a lesson from Debian packaging metadata here. Every mail transport agent, rather than conflicting with every other, has a "Provides: mail-transport-agent" and "Conflicts: mail-transport-agent", specifically because they all want to provide /usr/sbin/sendmail and (usually) listen on port 25. Unit files could do something similar, if systemd had an appropriate "virtual service" mechanism. That would then allow the simultaneous installation of several services that need a conflicting set of resources (for instance, several services that all need to listen on the same port), leaving it to the sysadmin to determine which one to enable, and automatically disabling all the rest. Some integration with Debian's alternative mechanism could ensure that the currently enabled listener on port 25 always matches the provider of /usr/sbin/sendmail. Time synchronization services need to conflict as well, not necessarily because they all listen on the same port, but because they all want to control the system clock, and only one should do so. A simple "named resource" mechanism, and some collaboration to agree on common names for such resources (similar to names for virtual packages) would solve that. Likewise, display managers could all coexist and install appropriate unit files, but provide and conflict with a virtual service representing their control of the display, forcing at most one to run at once. Does that sound plausible? - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
