Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 81498

Summary: upgrade script should not put back files deliberately removed
Product: [Retired] Red Hat Linux Reporter: Neil Prockter <prockter>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED NOTABUG QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0Keywords: FutureFeature
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-01-20 15:48:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Neil Prockter 2003-01-09 22:34:05 UTC
Description of problem:
logrotate (perhaps rpm in general) upgrades replace files that have been
deliberately removed.
I remove /etc/logrotate.d/apache because I handle loging and I don't want apache
restarted every day
after upgrading logrotate the file is put back and apache gets restarted again.
this is undesirable 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.remove /etc/logrotate.d/apache
2.upgrade logrotate
Actual results:
/etc/logrotate.d/apache recreated

Expected results:
/etc/logrotate.d/apache left not there

Additional info:
maybe I'll try linking to /dev/null?

Comment 1 Elliot Lee 2003-01-13 21:23:53 UTC
This isn't logrotate's doing. rpm has to put the files there when you upgrade because it is 
impossible to always distinguish between the file having been removed and the file not 
ever having existed. A workaround might be to empty the file (not a symlink) instead of just 
removing it.

Comment 2 Neil Prockter 2003-01-13 22:59:52 UTC
it is possible to test the difference between not there and never been there.
the rpm can check whether the rpm was there before and check whether that
previous rpm contained that file.

If the previously installed rpm included that file but the file is no longer
there it could assume the file was removed on purpose

Comment 3 Jeff Johnson 2003-01-14 20:58:17 UTC
No way is rpm gonna be check the previous package
contents for "removed" files, and carry that
information forward. Many, many people rely on
reinstalling or upgrading a package to fix
accidental removals of files.

Comment 4 Neil Prockter 2003-01-14 22:11:39 UTC
not even as an option?

if not I need a global list of files that automatically --excludepath 'd, I can
put pahts/files that should never be upgraded or touched in there and continue
to use up2date (and rpm -Uvh with less thought!)

I can not live with files being recreated that I have deliberately removed

I see that end users need rpm to fix problems in a blanket manner, I need more
control than that

My specific logrotate example can cause dire consequences

(please forgive my lack of knowledge if this file already exists)

Comment 5 Jeff Johnson 2003-01-14 22:21:56 UTC
The "official" answer is
    rpm has way too many options already
but I'll be happy to look at a proposed patch.

Any option should be "opt-in", as there are people
who rely on rpm to "fix" accidentally removed files.

As always,
    Patches cheerfully accepted.

Comment 6 Jeff Johnson 2003-01-20 15:48:21 UTC
I'm oing to close this. Again, if you want this
functionality, then send me a patch.