On Tuesday, March 11, 2008 at 13:25:59 +0100, Karel Zak wrote: > The command line option should be optional. I think 99% of all users > is fine with /etc/adjtime. I also think so. And 99% of the remaining users would be fine with /var/lib/hwclock/adjtime. None of them would never need to use --adjfile (if hwclock checks both places by default). Only the 0.01% using yet another non-default place would need the option. But those would need to use it at every hwclock invocation, in bootup, cron, shutdown, whatever, and at the shell prompt. Surely doable, but probably not the most practical. > It's always bad thing when you can't change a setting (e.g. paths) > without recompilation. Very true. But the alternative is not option or nothing, but option or env var. I think that an ADJTIME_PATH to override the default adjfile is more adapted to this case, more handy for the minority needing it. On Tuesday, March 11, 2008 at 8:22:15 -0400, Mike Frysinger wrote: > On Tuesday 11 March 2008, Alain Guibert wrote: >> So a command line option to select a file doesn't make much sense, >> and would be prone to mismatches between various scripts, or be >> forgotten when the user invokes hwclock by hand. > global configuration files handle this. And for those global configuration files, the best way to give one adjfile to all hwclock calls is probably environment, isn't it? > admins dont really run hwclock by hand. Are you sure? ;-) Another point to discuss is precedence. If the default list of adjfiles is say "/etc/adjtime:/var/lib/hwclock/adjtime", hwclock uses the first found: /etc/adjtime should have the precedence. Good. If there is no adjfile nowhere, where should hwclock create a new one? I tend to think it should pick the first in list, creating /etc/adjtime. This because of history, of compatibility with other apps, and also because it suits the largest majority. Agreed? I tried to imagine a smarter scenario, like: try to create /etc/adjtime, but if it fails then create /var/lib/hwclock/adjtime, or something like that... But I can too easely imagine accidents where a transient failure would unnoticably lead forever to the wrong place. Alain. -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
