Bugzilla Bug 8423

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 an attachment (id=52335) [details]
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 an attachment (id=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. ***

(From update of attachment 52335 [details])
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] [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] [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 an attachment (id=102733) [details]
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] [details]
> 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 an attachment (id=102749) [details]
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. ***