Red Hat Bugzilla – Bug 107507
updating tzdata doesn't update /etc/localtime
Last modified: 2007-11-30 17:10:32 EST
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 chroot. Version-Release number of selected component (if applicable): tzdata-2003d-1
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.
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 tzdata-localtime).
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.
Instead of closing it, let's just reassign it to the component where this could actually be fixed.
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.
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 servers. 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 fi . /etc/sysconfig/clock if [ ! -f "/usr/share/zoneinfo/$ZONE" ]; then exit 0 fi 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).