chrony, time-daemon and ntp-server

Thank you for your report.
--
John Hasler
<email address hidden>
Elmwood, WI USA

# Automatically generated email from bts, devscripts version 2.9.7
clone 316549 -1
reassign -1 chrony
reassign 316549 ntp

Can I expect to see this bug fixed for etch?

http://bugs.debian.org/316549

Justin

What would be the operational benefit from having such a pseudopackage?

# Automatically generated email from bts, devscripts version 2.9.20
tags 316549 + moreinfo

retitle 316549 ntp: please provide time-daemon virtual package
tag 316549 - moreinfo
thanks

On Tue, Jun 06, 2006 at 07:08:47PM +0200, Peter Eisentraut wrote:
> What would be the operational benefit from having such a pseudopackage?
It's recommended by policy;
  /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz

Justin Pryzby wrote:
> > What would be the operational benefit from having such a
> > pseudopackage?
>
> It's recommended by policy;
> /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz

That is not an operational reason. The virtual package name list does
not specify the precise interfaces that a virtual package providing
package needs to offer, so by itself it's useless as a guideline.

# Automatically generated email from bts, devscripts version 2.9.20
tags 316549 + moreinfo

# Automatically generated email from bts, devscripts version 2.9.21
block 316549 with 391841

On Thu, Jun 08, 2006 at 08:17:53PM +0200, Peter Eisentraut wrote:
[time-daemon]
> > > What would be the operational benefit from having such a
> > > pseudopackage?
> > It's recommended by policy;
> > /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz
> That is not an operational reason. The virtual package name list does
> not specify the precise interfaces that a virtual package providing
> package needs to offer, so by itself it's useless as a guideline.

I've got one and I got mildly annoyed that this was not solved for ntp
yet. I just got a bugreport against my package which wants chrony to be
added to the `ntpdate | ntp' dependency of it. An accurate time is
needed for aiccu just like for Kerberos because it is included in the
handshake with the tunnel broker which will deny the IPv6 tunnel request
if the time is too far off (IIRC > 300s).

Thus I need to depend on some sort of time daemon, but only chrony and
openntpd provide time-daemon, ntp does not, which will force me to the
silly `ntpdate | ntp | time-daemon' dependency.

Currently chrony and openntpd block installation of ntp manually via a
seperate conflicts, instead of just conflicting against time-daemon.

Kind regards,
Philipp Kern

Am Mittwoch, 3. Oktober 2007 schrieb Philipp Kern:
> I've got one and I got mildly annoyed that this was not solved for ntp
> yet. I just got a bugreport against my package which wants chrony to be
> added to the `ntpdate | ntp' dependency of it. An accurate time is
> needed for aiccu just like for Kerberos because it is included in the
> handshake with the tunnel broker which will deny the IPv6 tunnel request
> if the time is too far off (IIRC > 300s).

I can only repeat my earlier answer: There is no definition of what a
time-daemon virtual package does, so it's a completely random guess as to
what should be done here.

(I'm the original submitter of #428211.)

> I can only repeat my earlier answer: There is no definition of what a
> time-daemon virtual package does, so it's a completely random guess as to
> what should be done here.

I can only agree with Peter, unfortunately. Like many other programs
in Debian, Aiccu only requires time accurate to a few minutes; it
could recommend one of a large number of packages, including ntp,
chrony, ntpdate, rdate, and probably many others I'm not familiar with.

The latter two clearly don't qualify as ``time daemons''. Perhaps the
ntp maintainers, the chrony maintainers, and the rdate maintainers
could get together to define a new pseudo-package suitable for such cases?

                                        Juliusz

forcemerge 316549 560717
thanks

--
BOFH excuse #427:
network down, IP packets delivered via UPS

Helo!

It's been some time since this bug/wishlist was filed, and since then
more packages have to workaround the situation in which 'ntp' package is
not part of the time-daemon virtual package by adding 'ntp |
time-daemon', instead of just Depending/Recommending/Sugesting the
'time-daemon' virtual package.

A quick reverse dependency package lists tell me that all this packages
have to unnecessarily require to depend on both ntp *and* time-daemon,
instead of just depending on 'time-daemon' as it would be expected:

aiccu
openafs-fileserver
slony1-bin

I might be wrong, but I consider the policy is quite straight forward in
this case as , and it's even specified on Debian's virtual-package list:
http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

System
------
[snip]
 linux-kernel-log-daemon a daemon to facilitate logging for the Linux kernel
 system-log-daemon a daemon that provides a logging facility for
other applications
 time-daemon anything that serves as a time daemon

Besides that, all of this packages have a possible exclusive-unwanted
Dependency/Recommendation/Suggestion on just 'ntp', requiring for an
specific software instead of asking for the provision of a service
through the virtual package 'time-daemon', as specified on the Debian
Policy 3.6: 'All packages should use virtual package names where
appropriate, and arrange to create new ones if necessary'.

switzerland
predict
predict-gsat
jffnms
hobbit-plugins
gnumed-client
gnome-system-tools
dovecot-common
education-networked
education-main-server
dancer-ircd
tucnak2
ltsp-client
ltsp-client-core

Please consider 'ntp' as a candidate for providing 'time-daemon'.

Greetings,

Dererk

--
BOFH excuse #361:
Communist revolutionaries taking over the server room and demanding all the computers in the building or they shoot the sysadmin. Poor misguided fools.