Keeping /etc/localtime up-to-date

[David Wolfskill]

Recent changes to /usr/share/zoneinfo have reminded me that my
regular updates to my FreeBSD machines via source update
/usr/share/zoneinfo, but /etc/localtime remains a copy of whatever
was in /usr/share/zoneinfo for the selected zone at the time
tzsetup(8) was last run -- and I certainly don't run tzsetup as
often as I update my sources (nor would I want to).

And while I (think I) recall that the equivalent of /etc/localtime
was implemented in some version of SunOS many years ago as a symlink,
I believe that approach could be problematic for FreeBSD, as it
could impose some unintended requirements on some of the start-up
scripts.

I believe that it would be appropriate to have a facility to update
/etc/localtime if the file to which it is supposed to correspond
in /usr/share/zoneinfo (now) differs.

Even if tzsetup is invoked with the -s flag and having the desired
zoneinfo file specified on the command-line, it goes into full-screen
mode and requests confirmation.  Further, if the confirmation is
given, it unconditionally overwrites /etc/localtime.

It would (in principle) be possible to teach mergemaster(8) how to
do this (possibly by including a cookie in ~/.mergemasterrc or
/etc/mergemaster.rc to tell it what the "reference" zoneinfo pathname
is), but this type of approach seems sufficiently different from
(the bulk of?) what mergemaster does currently that I'm unconvinced
that this is reasonable, let alone ideal.

So it seems to me that requirements would be:
* The content of /etc/localtime must provide the appropriate
  "zoneinfo" information, even when /usr/share/zoneinfo/* has been
  modified (or shortly thereafter, in concert with "make installworld").

* The content of /etc/localtime must be available when the only file
  system mounted is the root file system (and prior to any attempt to
  start any services (ref. {,/usr/local}/etc/rc.d)).

* The process must be amenable to automation; to that end, it must be
  possible to perform it without requiring confirmation, and it
  must be doable from a command-line.

* /etc/localtime should not be modified unless the content prior to
  modification differs from the selected specification in
  /usr/share/zoneinfo.

* The process should not add unnecessary complexity to existing tools
  and procedures.

  
As a crude, brute-force hack, what I did (yesterday) was:
* Create a symlink (which I called "/etc/tz") pointing to an
  appropriate zoneinfo entry.

* Augment the commands I run on successful completion of "make
  installkernel" (from src/UPDATING):

  mergemaster -p
  make installworld
  mergemaster -i
  make delete-old

  by appending

  cmp -s /etc/tz /etc/localtime || cp -p /etc/tz /etc/localtime

  to the set.

  While I make no claim as to elegance, I believe it meets the
  requirements I listed.


Of course, another approach -- which is likely to be fairly popular
-- would be to run the machine on UTC, and let folks who want to
care about TZ stuff set their own personal TZ environment variables.  :-}
Still, even that approach leads to the existence of /etc/localtime
as being somewhat of an "attractive nuisance" (in that if it exists,
it is likely to lead to a degree of mischief).

Thoughts?

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20110327/28d267a8/attachment.pgp