Description of problem: engine-setup does not add to uninstall.d files that were not changed by it. Therefore, engine-cleanup does not remove them. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. engine-setup 2. engine-cleanup, choose to not delete pki 3. engine-setup 4. engine-cleanup Actual results: /etc/ovirt-engine/engine.conf.d/10-setup-pki.conf is not removed Expected results: /etc/ovirt-engine/engine.conf.d/10-setup-pki.conf is removed by cleanup Additional info:
The idea is to not clean files that are not changed. This whole partial cleanup is something that we should stop supporting. But... if we do want to support it, just leave the uninstall information at partial cleanup for these groups that are not removed.
Proposing this for 3.3.1.
Some further thoughts: I think we should keep hashes of all files, not only ones we actually modified, and that upgrade should check them too and alert if files are missing or their hashes changed. Such files should not be deleted on cleanup. Actually I think that we should keep per file whether it existed or newly-created and only delete on cleanup files that did not exist.
(In reply to Yedidyah Bar David from comment #3) > Some further thoughts: I think we should keep hashes of all files, not only > ones we actually modified, and that upgrade should check them too and alert > if files are missing or their hashes changed. Such files should not be > deleted on cleanup. Actually I think that we should keep per file whether it > existed or newly-created and only delete on cleanup files that did not exist. we do not write rpm (or any package management) replacement. what we do not touch (create/modify) we leave for the distro package management to handle using its standard procedures.
Going with solution proposed in comment #1?
(In reply to Sandro Bonazzola from comment #5) > Going with solution proposed in comment #1? what I think is that the uninstall file should be left if any component is left.
(In reply to Sandro Bonazzola from comment #5) > Going with solution proposed in comment #1? Seems so, but as commented later, that's only part of the issue. Not sure it should be considered for zstream. I'll try to find a scenario where this solves a real problem, besides partial cleanup.
(In reply to Yedidyah Bar David from comment #7) > Not sure it should be considered for zstream. I'll try to find a scenario > where this solves a real problem, besides partial cleanup. I too do not think this worth z-stream, partial uninstallation is something I consider experimental.
(In reply to Alon Bar-Lev from comment #4) > we do not write rpm (or any package management) replacement. > what we do not touch (create/modify) we leave for the distro package > management to handle using its standard procedures. If an upgrade overwritten /etc/sysconfig/iptables, an admin did some manual changes, I think it's nice if a later upgrade will warn the admin that his changes will be overwritten.
(In reply to Alon Bar-Lev from comment #8) > (In reply to Yedidyah Bar David from comment #7) > > Not sure it should be considered for zstream. I'll try to find a scenario > > where this solves a real problem, besides partial cleanup. > > I too do not think this worth z-stream, partial uninstallation is something > I consider experimental. I agree, moving this to 3.4.0.
Re-targeting to 3.4.1
Some other changes in cleanup are planned for 3.6. I do not think we'll backport, and this bug in itself is not urgent. Postponing for now.
Closing old RFEs (this one specifically has been dragging for ~4 years from release to release).
(In reply to Yaniv Kaul from comment #14) > Closing old RFEs (this one specifically has been dragging for ~4 years from > release to release). I tend to agree about the specific subject of current bug, but we still might consider comment 3 and comment 9. In practice, the specific issue of comment 9 was already handled later on (bug 1109326) - if we handled current earlier, it would (partially) make the other redundant. Quickly reviewing our setup code, I think we have almost no other similar examples - all the rest is either edited in-place, not blindly overwritten - e.g. /etc/httpd/conf.d/ssl.conf - or is owned by engine-setup - e.g. all stuff under /etc/ovirt-engine and /etc/pki/ovirt-engine. For the latter, it would still be nice if we checked and alerted if user changed them manually.