Bug 54735 - Update of glibc touches /etc/localtime.rpmnew
Summary: Update of glibc touches /etc/localtime.rpmnew
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-10-17 13:06 UTC by Christian Rose
Modified: 2016-11-24 14:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-17 13:06:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Christian Rose 2001-10-17 13:06:43 UTC
On two RHL 7.0 systems, I upgraded to glibc-2.2.4-18.7.0.

The update warned about having created an /etc/localtime.rpmnew. Since this
is a binary file and I could not spot differences, and since the update
touched this file and I thus thought it really should be updated, I did a
"mv /etc/localtime.rpmnew /etc/localtime".

I shouldn't have done that, I realize afterwards, because from that point
on my system kept EDT as timezone, as opposed to the correct CEST. I could
only resolve this by "cp /usr/share/zoneinfo/posix/Europe/Stockholm
/etc/localtime".Proposed solution: Updates of glibc should not care about
the /etc/localtime file.

Comment 1 Jakub Jelinek 2001-10-17 16:06:07 UTC
That's normal rpm behaviour. /etc/localtime has to be IMHO part of glibc,
so that running timeconfig is not strictly necessary, and is %config(noreplace)
exactly so that it doesn't blow away your own setting. Blindly copying
.rpmnew files to the original files is a bad idea.

Comment 2 Christian Rose 2001-10-17 17:01:35 UTC
> Blindly copying .rpmnew files to the original files is a bad idea.

I always diff rpmnew files, but since this is a binary file, that was hardly
helpful. That's the problem - it creates a rpmnew file although none should be
needed. But maybe this is more of a problem with rpm.




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