ntpdate package and g-s-t disagree over where ntpdate symlink should be installed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
system-tools-backends |
Won't Fix
|
Medium
|
|||
gnome-system-tools (Ubuntu) |
Invalid
|
Medium
|
Ubuntu Desktop Bugs | ||
liboobs (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
system-tools-backends (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
sysvinit (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
upstart (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Package: gnome-system-tools
Version: 1.3.0.1-0
The ntpdate package installs an S symlink for ntpdate in
/etc/rcS.d/. I disabled this by hand: I renamed it from
S51ntpdate to K51ntpdate. (This is the correct way to disable
a script in rcS.d/.)
I ran g-s-t "Services" manager and enabled ntpdate. It
created an S50ntpdate symlink in the current multiuser runlevel
(3), leaving the K symlink in rcS.d/ still present. This less
than ideal. If 3:S50ntpdate is the proper location for the
S symlink then the ntpdate package should not put an S symlink
in rcS.d/. If rcS.d/ is the right place for the symlink then
g-s-t should not put one in the current multiuser runlevel.
http://
Changed in upstart: | |
status: | New → Invalid |
Changed in sysvinit: | |
status: | New → Invalid |
Changed in system-tools-backends: | |
status: | Unknown → New |
Changed in system-tools-backends: | |
importance: | Unknown → Medium |
Changed in gnome-system-tools (Ubuntu): | |
status: | Triaged → Invalid |
Changed in system-tools-backends: | |
status: | New → Won't Fix |
Thanks for your bug, I've forwarded it upstream: bugzilla. gnome.org/ show_bug. cgi?id= 310913
http://