On Wednesday 19 March 2008, Alain Guibert wrote: > On Tuesday, March 18, 2008 at 1:53:11 +0100, Karel Zak wrote: > > Where do you want to define the $ADJTIME_PATH? /etc/profile? ;-) > > /etc/profile is maybe not the best place, because it is not above the > bootup and shutdown scripts, main callers of hwclock. I would suggest > a more upstream place, like /etc/initscript or such. Or a main config > /etc/default/hwclock.sh sourced by /etc/profile and by boot scripts. > Or whatever else: really distributors and sysadmins are free to do as > they prefer. Even define the var only in scripts and root's env, or only > in a wrapper. as you point out, these are all distribution concerns, not util-linux. and if distributions need to change things anyways, there is no real argument for env var over cmdline option. just the other way: env vars do not fit up very well at all with core utilities. you want to change behavior, you use a flag. or you just throw out the whole discussion and tell people to create a symlink to wherever they want: /etc/adjtime -> /var/lib/foo > A private /etc/hwclock.conf would cover as much hwclock calls as > $ADJTIME_PATH, and have less public exposure. But it is a quite heavy > solution. While the env var solution is extra light. sounds ugly. one config file for one setting ? and we trade one standard config file in /etc for another (not they have the same purpose -- one is a state file) ? then again, /etc/hwclock.conf sounds slightly better than an env var, but not as good as a cmdline option. > In any case --adjfile seems disqualified, at least as the sole method. > And there is probably no urgency to implement several methods for such > a marginal usage. if we're going to make the file location dynamically controlled, then a cmdline option is a must. anything else (env var / config file / whatever) is above that. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
