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 - upgrade script should not put back files deliberately removed
Summary: upgrade script should not put back files deliberately removed
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-09 22:34 UTC by Neil Prockter
Modified: 2007-04-18 16:49 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-01-20 15:48:21 UTC


Attachments (Terms of Use)

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:
everytime


Steps to Reproduce:
1.remove /etc/logrotate.d/apache
2.upgrade logrotate
3.
    
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.


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