Bug 107507 - updating tzdata doesn't update /etc/localtime
updating tzdata doesn't update /etc/localtime
Product: Fedora
Classification: Fedora
Component: tzdata (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
Blocks: 106572
  Show dependency treegraph
Reported: 2003-10-19 13:57 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-06 15:29:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2003-10-19 13:57:41 EDT
There should probably be a postinstall script on tzdata that updated
/etc/localtime based on the timezone name in /etc/sysconfig/clock.  A
postinstall script would be better than say a trigger in redhat-config-date
because then you can be sure that other packages that trigger on tzdata updates
to update /etc/localtime in their chroots (say bind-chroot) will always be run
after /etc/localtime was updated.  AFAIK triggers might be run in arbitrary
orders, which might result in an out-of-date /etc/localtime being copied to a

Version-Release number of selected component (if applicable):
Comment 1 Jakub Jelinek 2003-10-20 09:12:26 EDT
This is not possible because of the dependency chain (where glibc-common
needs to depend on tzdata). This means tzdata cannot invoke shell in its %post.
This really has to be a redhat-config-date %trigger if anything.
Comment 2 Alexandre Oliva 2003-10-20 10:28:55 EDT
I don't quite see why redhat-config-date should be responsible for updating
/etc/localtime.  Could we perhaps have tzdata-localtime, built out of tzdata and
depending on the same version of tzdata, that would own /etc/localtime, and
update it from tzdata whenever both are upgraded?  Then other packages that
depend on /etc/localtime would trigger on it, instead of on some other random
package.  This seems a bit over-engineered, but I don't see a simpler solution
that offers the kind of guarantees I think we should offer, and that even gives
the user the option of maintaining /etc/localtime themselves (by removing
Comment 3 Brent Fox 2004-03-09 22:38:21 EST
redhat-config-date will update /etc/localtime if the timezone is
changed, but that is all.  Having a %trigger in redhat-config-date to
update /etc/localtime when the configuration tool has not even been
run doesn't seem like the right thing to do.  I agree with lxo that
this seems outside the scope of redhat-config-date.
Comment 4 Alexandre Oliva 2004-03-18 22:57:57 EST
Instead of closing it, let's just reassign it to the component where
this could actually be fixed.
Comment 5 Jakub Jelinek 2004-10-06 15:29:41 EDT
But it can't be fixed in tzdata either.  tzdata is a noarch package,
so even a statically linked %post that would do the copy is not
an option.
Comment 6 Aleksandar Milivojevic 2005-11-08 12:35:34 EST
A postinst script in redhat-config-date (or system-config-date?) is not a
solution.  I don't have any of (redhat|system)-config-.* stuff installed on my

Since /etc/localtime is owned by glibc package, logical place to put trigger is
glibc package itself.  Whenever tzdata is upgraded, glibc should reconfigure the
file it owns.  Chrooted packages (such as bind-chroot) should also include a
trigger to update their own copies of localtime file.

For example something like this script.  I don't know if its OK to have sh
trigger script in glibc (if not, it could be statically linked executable that
does the same thing).

%triggerin -- tzdata
if [ ! -f /etc/sysconfig/clock ]; then
    exit 0
. /etc/sysconfig/clock
if [ ! -f "/usr/share/zoneinfo/$ZONE" ]; then
    exit 0
cp -f "/usr/share/zoneinfo/$ZONE" /etc/localtime
exit 0

If I got documentation right, this trigger would be invoked when either:

1) glibc package is installed or updated
2) tzdata package is installed or updated

The only thing is initial installation.  I don't know when Anaconda generates
/etc/sysconfig/clock file (I guess Anaconda generates this file during either
preinstall or postinstall?).  But I guess Anaconda could be updated to simply
generate the file in preinstall stage if needed (after file systems are created
and mounted).

Note You need to log in before you can comment on or make changes to this bug.