Bug 107507 - updating tzdata doesn't update /etc/localtime
Summary: updating tzdata doesn't update /etc/localtime
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: tzdata
Version: 1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 106572
TreeView+ depends on / blocked
 
Reported: 2003-10-19 17:57 UTC by Alexandre Oliva
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-10-06 19:29:41 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alexandre Oliva 2003-10-19 17:57:41 UTC
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

Comment 1 Jakub Jelinek 2003-10-20 13:12:26 UTC
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 14:28:55 UTC
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).

Comment 3 Brent Fox 2004-03-10 03:38:21 UTC
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-19 03:57:57 UTC
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 19:29:41 UTC
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 17:35:34 UTC
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).



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