Bug 23461 - want more control over md5 checksums
want more control over md5 checksums
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
David Lawrence
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2001-01-05 21:02 EST by Steve Fink
Modified: 2007-04-18 12:30 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-01-05 21:02:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steve Fink 2001-01-05 21:02:41 EST
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 02:18:57 EST
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
config file handling should (but you best check) save the previously installed
(and locally modified) file when your package is upgraded with the above

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.