[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#731594: debian-installer: time synchronisation should be installed by default



reassign 731594 ntpdate
retitle 731594 Please make ntpdate package priority standard
thanks

On 7 December 2013 10:25, Thiemo Nagel <thiemo.nagel@gmail.com> wrote:
>
> Package: debian-installer
> Severity: normal
> Tags: d-i
>
> Hello,
>
> I think that a modern OS should take care of time synchronisation without
> requiring user intervention. As far as I can see, Debian doesn't install any
> kind of NTP client by default. (I'd guess that it falls back behind Mac and
> Windows in this regard. Even my mobile phone synchronises time automatically.)
>
> Thus, I'd suggest to install as part of the base system an NTP package
> (eg. ntp, openntpd, chrony) configured to act as client only.
>
> This issue has already been discussed nine years ago, however I believe that
> user's expectations have changed through the passage of time and thus a fresh
> look at the topic may be warranted.
>
> http://bugs.debian.org/397649
>

I fully agree that ntp client should be installed by default. Checking
dependencies of the available candidates (such that we can see what
other packages they pull into standard set):
* ntp - libopts25 (optional)
* ntpdate - all good
* openntpd - all good
* chrony - timelimit (optional)

Nothing too scary.

The other concern raised was people on intermittent and metered
connections (3G / dial-up), who may not want to have a daemon running
that can't do anything, nor a daemon that would establish unwanted
internet connections. To this extend ntpdate is the best package, as
it is only executed upon network configuration without a long running
daemon, nor periodic cron job.

To resolve this bug report one of the above packages should become
priority standard. From d-i point of view, any would do =)

I recommend for ntpdate to become such one. Therefore I am reassigning
this bug to package "ntpdate" for its maintainer to consider this
change.

Regards,

Dmitrijs.


Reply to: