Bug 186742

/var/spool/postfix/etc/localtime is also not updated by a tzdata upgrade. 
 

> /var/spool/postfix/etc/localtime is also not updated by a tzdata upgrade. 

Or any localtime file in chroot jails, such as in /var/named/etc.

The problem goes back as far as RH 7.x, at least.

This bug has wide impact, since users in some states of Australia which have not
copied /usr/share/zoneinfo/Australia/... to /etc/localtime (eg, by running
system-config-date) since tzdata 2005m was released have the wrong time for the
coming week.

Fix is to create a RPM postinstall script which checks for ZONE in
/etc/sysconfig/clock and copies "/usr/share/zoneinfo/$ZONE" to /etc/localtime.

The traditional approach is for /etc/localtime to be a symlink to
/usr/share/zoneinfo/$ZONE (or whatever is appropriate), but if it's supposed to
be possible to boot a machine without /usr mounted, a copy in a post-install
script in the tzdata rpm might be a better approach.

*** Bug 186743 has been marked as a duplicate of this bug. ***

After running system-config-date, the /etc/localtime file gets updated, so this
can be fixed on affected machines quite simply. I'll look if there is something
that prevents the file to be copied upon postinstall.

There is another point where this problem will occur:
/var/name/chroot/etc/locatime
Again the postinstall process for both tzdata and caching-nameserver will need
to consider this.

(In reply to comment #6)
> After running system-config-date, the /etc/localtime file gets updated, so this
> can be fixed on affected machines quite simply. I'll look if there is something
> that prevents the file to be copied upon postinstall.

Apparently, Fedora Core 5 comes with a little utility /usr/sbin/tzdata-update,
that parses /etc/sysconfig/clock for the TZ variable and copies the appropriate
zone file over /etc/localtime. It gets called by the tzdata post-update scipt.

Maybe this mechanism can simply be back-ported to FC4?

If this previous comment is correct (I haven't checked) then it needs to also
take account of /var/named/chroot/etc/localtime where it exists, as per my
previous comment #7

*** Bug 186777 has been marked as a duplicate of this bug. ***

This can't be done. There is no guarantee that shell and coreutils are here when
tzdata %post is fired. I'd like to have this fixed, people often ask for it, but
there is no straightforward way. Wontfix.

OS X 10.4 Macs and Windows XP managed the switchover ok (though Windows can only
do so by breaking historical times) and Debian managed it fine, but there's no
way to fix this in Fedora Core?!?

Making /etc/localtime a symlink is better than having the time break.  I guess
I'll have to go around and do that by hand...

(In reply to comment #11)
> This can't be done. There is no guarantee that shell and coreutils are here when
> tzdata %post is fired. I'd like to have this fixed, people often ask for it, but
> there is no straightforward way. Wontfix.

If this is the case, then surely a warning would be in order.  tzdata gets
regularly updated for many global situations and this is too important to just
let slide without either fixing or warning.

If the showstopper to this bug being fixed is: "There is no guarantee that shell and coreutils are here when tzdata %post is fired." (and presumably the same for glibc-common), then let's think of another solution.  A cron job?  A test for the presence of the shell/coreutils before endavouring to update from within %post?  (After all, this is an issue only for updates, not for initial installs.)

glibc has a hook responsible for updating tzdata.  AFAI recall, it's written in such a way that it doesn't need even glibc, much less coreutils.  This should now be taken care of.

Actually, now that we have UsrMove in effect and /usr can't be mounted separately anymore, there's no reason not to make /etc/localtime a symlink.