Bug 81498
| Summary: | upgrade script should not put back files deliberately removed | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Neil Prockter <prockter> |
| Component: | rpm | Assignee: | Jeff Johnson <jbj> |
| Status: | CLOSED NOTABUG | QA Contact: | Mike McLean <mikem> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | Keywords: | FutureFeature |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | |
| Embargoed: | |||
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. 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 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. 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) 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.
I'm oing to close this. Again, if you want this functionality, then send me a patch. |
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?