One minor thing: what about checking the rc-updates at package removal? It really makes no sense eg. to leave the rc script for starting exim if I've emerge -C -ed exim already :)
Not sure if we want to be that clean. We generally leave config files in place.
from bug 15421 ... add a '--nuke' or like '--veryclean' cmdline option that'll allow people to remove all files that were installed regardless of mtimes
*** Bug 15421 has been marked as a duplicate of this bug. ***
*** Bug 24476 has been marked as a duplicate of this bug. ***
*** Bug 25759 has been marked as a duplicate of this bug. ***
I'd realy like such a feature. /etc gets very crouded on Gentoo, mine is 20M, and thats after some light cleaning. Whats the point in leaving config files behind? They're not in use. If a --config-clean option was introduced, it could spit out a warning telling people to backup thier configs if needed. They would then have the 5 second count-down to decide.
To delete initscripts/configfiles on unmerging you could simply add /etc/init.d or /etc to CONFIG_PROTECT_MASK (in make.conf or on the commandline) temporary. I don't like the idea of a new emerge switch if there is already a simple solution to do this.
There is no flag needed. Just a hash for each config file which is created while merging, removing unchanged files on unmerging and printing/logging the ones which remain. The config file protection prevents deleting/overwriting existing config files and does _not_ help to delete useless files (e.g. if you accidentally emerged apache2 or switched from syslog to syslog-ng).
^^ sysklogd to ...
My suggestion would be to make a standalone tool along the lines of app-admin/localepurge.
*** Bug 30287 has been marked as a duplicate of this bug. ***
*** Bug 37905 has been marked as a duplicate of this bug. ***
*** Bug 43066 has been marked as a duplicate of this bug. ***
*** Bug 46162 has been marked as a duplicate of this bug. ***
How about just adding some output to the end of an emerge that resulted in a removal being performed...just a simple list of config files that are no longer in use. I got bit by the vcron->vixie-cron thing, bug 37905. If at the end of the operation, emerge said "By the way, /etc/init.d/vcron is no longer used," I would have known to delete it. Just a thought...
*** Bug 56291 has been marked as a duplicate of this bug. ***
*** Bug 66609 has been marked as a duplicate of this bug. ***
Well, just one more replying on this thread here. All people I know that use Gentoo say one thing about it. That it badly misses a purge function like it is on Debian for a long time. Please add one function like that. Cheers
*** Bug 83538 has been marked as a duplicate of this bug. ***
Created attachment 52335 [details, diff] disable config protect when unmerging This very simple patch disables config protect when unmerging package. Changed (mtime) files are not removed.
Would this patch exhibit the problem described in comment 6 of Bug 43066?
Created attachment 57230 [details] A very dangerous script ;) This script takes a finite number of directories as arguements as well as options. See localpurge --help for available options. This script will get a file list of files in each dir specified on the command line. It will then fetch a list of currently installed packages, and their CONTENTS ( meaning files they own ). It then compares the files in the current dir against the CONTENTS of every installed package. If a file is not found in any installed pkg's CONTENTS it is marked as orphaned. The script supports recursion with the --recurse option. It will print out orphaned files by default. To have it prompt you for files to delete, pass the --remove option. To have it auto-delete the files ( NOT RECOMMENDED ) add the --force option. To stop all the annoying .....'s try the --quiet option. Note: Running this as "localpurge / --remove --recurse --force" has the potential to completely destroy your system. This script will remove any files not owned by an installed package, which in some cases means IMPORTANT FILES. Always use --scan first, and carefully chose what you want gone.
Er. bugs with that go to me warnera6@egr.msu.edu, not here BTW :)
*** Bug 98913 has been marked as a duplicate of this bug. ***
*** Bug 125655 has been marked as a duplicate of this bug. ***
*** Bug 125722 has been marked as a duplicate of this bug. ***
I vote for an --exterminate (-X) or --zap (-Z) option, which would remove all files which were merged, after displaying a warning about this (like suggested). That way you could keep /etc much cleaner.
*** Bug 135918 has been marked as a duplicate of this bug. ***
just an idea for the discussion: i generally have: /etc/make.conf: AUTOCLEAN="no" on all machines i manage. what i do when upgrading something is: # emerge something # etc-update # CONFIG_PROTECT="-*" emerge clean and sometimes: # emerge something # CONFIG_PROTECT="-*" emerge clean # etc-update this cleans out old untouched config files before diffing when unmerging: # CONFIG_PROTECT="-*" emerge unmerge something so untouched and unneeded config files are removed -> that avoids cruft i think this config file handling should be default on portage so my split emerge and emerge clean then could be avoided.
(In reply to comment #29) > just an idea for the discussion: > > i generally have: /etc/make.conf: AUTOCLEAN="no" on all machines i manage. [...] > i think this config file handling should be default on portage so my split > emerge and emerge clean then could be avoided. Definitely not. AUTOCLEAN=no is not supported at all and might be dropped in the future.
*** Bug 136461 has been marked as a duplicate of this bug. ***
Comment on attachment 52335 [details, diff] disable config protect when unmerging The patch breaks one (fairly common) case: You merge version 1 of a package that installs a config file. The user doesn't touch the file. Then, you upgrade that package to version 2. Portage will now put a ._cfg0000_config file into the system and remove the original, leaving the new version as orphaned update there effectively.
(In reply to comment #32) > (From update of attachment 52335 [details, diff] [edit]) > The patch breaks one (fairly common) case: > > You merge version 1 of a package that installs a config file. The user doesn't > touch the file. Then, you upgrade that package to version 2. Portage will now > put a ._cfg0000_config file into the system and remove the original, leaving > the new version as orphaned update there effectively. I can't imagine it would be that common.. collision-protect will choke on the case where two packages share the same config files.
Or not... Ok, I'll shut up again.
It doesn't have to be another package, another version is sufficient to break it. It's really a typical upgrade scenario :)
(In reply to comment #32) > (From update of attachment 52335 [details, diff] [edit]) > The patch breaks one (fairly common) case: > > You merge version 1 of a package that installs a config file. The user doesn't > touch the file. Then, you upgrade that package to version 2. Portage will now > put a ._cfg0000_config file into the system and remove the original, leaving > the new version as orphaned update there effectively. I suppose the merge phase can be made a little smarter so that it detects such a situation in advance and automatically overwrites the untouched config file. Before the merge phase merges a config protected file, it will have check the for a collision with the currently installed package in the same slot and then see if the colliding file is eligible to be unmerged. If so, it can immediately overwrite the file.
Created attachment 102733 [details, diff] allow the merge phase to overwrite untouched config files This patch should do the job. Because of bug #16162, we'll also have to modify etc-update and dispatch-conf so that they don't touch the mtime when they merge a config file.
(In reply to comment #37) > Because of bug #16162, we'll also have to modify > etc-update and dispatch-conf so that they don't touch the mtime when they merge > a config file. Well, we don't really have to modify etc-update and dispatch-conf. As long as the user never modifies the config files of a package, config protection should never be triggered. So, my patch alone should solve the problem.
This is fixed in svn r5129.
(In reply to comment #37) > Created an attachment (id=102733) [edit] > allow the merge phase to overwrite untouched config files That's not a very good idea if configuration file changes introduce behaviour changes. Simple example: Old version of foo defaults to looking in /var/foo for its data. The user is happy with this. New version of foo comes along, and defaults to looking in /srv/foo for its data. The user does not want this. The user upgrades. The user has their foo files in /var/foo. The user restarts foo. Suddenly their foo no longer has any data.
(In reply to comment #40) > New version of foo comes along, and defaults to looking in /srv/foo for its > data. The user does not want this. That seems like a reasonably likely scenario. I'll fix it so that config protection is triggered in that case.
Created attachment 102749 [details, diff] when necessary, bump the mtime to prevent uninstallation of config protected files This updated version of the previous patch will never overwrite an untouched config file. In cases where an installed package in the same slot owns a protected file that will be merged, the mtime is bumped on the installed file in order to ensure that it isn't unmerged.
In svn r5134:5136 etc-update and dispatch-conf are fixed so that they don't unnecessarily modify mtime when the user replaces an old config file with an update that the user hasn't modified.
I'd just like to reference my attempted report of a package update bug (udev) that is being summarily dismissed by a hostile bug-wrangler, without even a single moment of thought: http://bugs.gentoo.org/show_bug.cgi?id=156505 If a package update fails to remove former package files that are no longer needed, I'd call that a bug. Further, if the package update results in an inability of the package to run, requiring manual intervention, I'd also call that a bug in the update process. And yes, I did run etc-update. Peace.
This has been released in 2.1.2_rc2-r3.
*** Bug 158934 has been marked as a duplicate of this bug. ***
*** Bug 20223 has been marked as a duplicate of this bug. ***
*** Bug 42027 has been marked as a duplicate of this bug. ***
*** Bug 164765 has been marked as a duplicate of this bug. ***
*** Bug 165258 has been marked as a duplicate of this bug. ***
*** Bug 166083 has been marked as a duplicate of this bug. ***
Why is this "FIXED" since 2006 when the problem persists in the current stable portage? As I understand, it has been fixed only a month ago with FEATURES=config-protect-if-modified commit (http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=770bb7ae), portage 2.1.10.44 has it (~amd64 yet)
(In reply to comment #52) > Why is this "FIXED" since 2006 when the problem persists in the current stable > portage? > As I understand, it has been fixed only a month ago with > FEATURES=config-protect-if-modified commit > (http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=770bb7ae), > portage 2.1.10.44 has it (~amd64 yet) As I understand it, this bug report was about a different but somewhat related issue. See these commits: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1e97aecdc2b27ff3a78ee4061eaa712b6d667980 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=bb5bb2180186cd5cf138f4d17bb315e228d0a563
