On Tue, 2006-03-28 at 07:11 +0100, Paul Howarth wrote: > I always get a /etc/localtime.rpmnew when there's a glibc update. Same > again today on my last FC4 box. This is all messed up. In the olden days (RH Linux), zone files were part of glibc-common and /etc/localtime was part of glibc. I wonder what the content of the original /etc/localtime was (as found in the package) - it would have been pretty nonsensical for most parts of the world. Things are slightly different in Fedora (as of FC4 at least). Zone files are part of the new tzdata package, and /etc/localtime still comes with glibc. However, no /etc/localtime.rpmnew file ever got created on my FC4 systems. Maybe your's stems from RH Linux days? When zone file updates actually made an attempt to do the right thing? That said, I reckon the right thing to do would be creating a .rpmsave file, and overwriting localtime with the new zone definition. > As far as rpm's > concerned, /etc/localtime is just another config file and it treats it > like any other changed config file, hence the .rpmnew version. Well, it isn't a config file as such, it's not supposed to be edited. It's a copy of one out of a selection of files. In Solaris, /etc/TIMEZONE is a proper config file, and contains a string like "TZ=Australia/NSW". The zone file pointed to lives under /usr/share/lib. In OpenBSD, /etc/localtime is a symlink to the real zone file under /usr/share. Both Solaris and OpenBSD have to deal with the fact that the default time zone is not known until /usr gets mounted. Which isn't really a big deal, apart from system log files that insist on using local time for time stamps (a bug IMHO). If there are good reasons for Linux to have the default time zone known before /usr is mounted (dual-boot with Windows maybe) then I can accept that. In that case, tzdata updates must adjust /etc/localtime (which shouldn't be a part of glibc either). Time zone changes are legislated, it is not up to the individual admin to decide whether to implement them or not. Therefore, a .rpmnew file would be wrong, too. Cheers Steffen.
Description: This is a digitally signed message part