Bug 23461 - want more control over md5 checksums
Summary: want more control over md5 checksums
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm   
(Show other bugs)
Version: 6.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-01-06 02:02 UTC by Steve Fink
Modified: 2007-04-18 16:30 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-06 02:02:43 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 Steve Fink 2001-01-06 02:02:41 UTC
As I understand it, the md5 checksums are generated for everything in
%files at build time. These are used to do the foo -> .rpmsave/.rpmorig
config file magic.

I have a config file that I want to tailor to the installed machine's
environment (eg putting in a line MYWEBROOT=http://`hostname`/top). But I
also want that config file to be governed by the .rpmsave config file
management magic.

So maybe I'm misunderstanding the philosophy, but I want a directive that
allows me to change the recorded md5 sum as part of the %post section. (Or
an %attr directive that says to compute the md5 checksum for chosen files
after %post completes.)

Comment 1 Jeff Johnson 2001-01-06 07:18:57 UTC
Best I can suggest is to add the directive
	%verify(nomd5) %config <your.conf>
to turn off md5 verification of a locally modified file when verifying. The
existing
config file handling should (but you best check) save the previously installed
(and locally modified) file when your package is upgraded with the above
directives.

Adding a directive to reset the md5 sum is not possible because there are 3 md5
sums involved in config file handling
	the file that is actually on the file system
	the file in the old package, already installed
	the file from the new package, about to be installed
and added directives to handle the mishmosh would be complex at the minimum,
and a possible security problem as well.

Hope that helps.
	


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