When I remove a pakage using 'emerge -C' why does it leave entires in
/etc?

For example I was trying to remove apache so ran 'emerge -C apache',
but later on I've found /etc/init.d/apache2, /etc/conf.d/apache2 and
not to mention /etc/apache2/ still exist.

Any ideas?

TIA.

BinaryFrost wrote:

> When I remove a pakage using 'emerge -C' why does it leave entires in
> /etc?
>
> For example I was trying to remove apache so ran 'emerge -C apache',
> but later on I've found /etc/init.d/apache2, /etc/conf.d/apache2 and
> not to mention /etc/apache2/ still exist.
>
> Any ideas?

Short answer: It's designed that way.

Longer answer: Portage automatically protects configuration files during
merging of updates and unmerges. Usually these files contain changes
made by the user, so removing them might destroy some work that one
wants to keep. I think it was supposed to remove files with that were
not changed, so I'm curious as to why /etc/init.d/apache2 remains. Did
you make some changes to it, or perhaps merge it with an older version
in the wrong way?

--
PeKaJe

Microsoft products are easy to administrate. Anyone can do it!
Even if you don't want them to ... -- Jim Richardson, in COLA

So anyway, it was like, 12:21 CET Feb 04 2006, you know? Oh, and, yeah,
Peter Jensen was all like, "Dude,
> BinaryFrost wrote:

[random snippage]

>> When I remove a pakage using 'emerge -C' why does it leave entires
>> in /etc?

> Short answer: It's designed that way.

Alternative short answer: 'man make.conf', 'emerge --help config'

> Longer answer: Portage automatically protects configuration files
> during merging of updates and unmerges.

What controls this behaviour is the flag CONFIG_PROTECT, which is set
by default (at least) in /etc/make.globals, likely to just /etc. No
files in that directory will then be deleted when unmerging a package,
however (as far as I know) unchanged files will be overwritten when
merging a package.

To "unprotect" a directory (for example /etc/init.d, which you might
wish to keep clean), add it to the CONFIG_PROTECT_MASK flag.

--
Time flies like an arrow, fruit flies like a banana. Perth ---> *
12:37:57 up 87 days, 19:11, 2 users, load average: 1.14, 0.88, 0.38
Linux 2.6.14 x86_64 GNU/Linux Registered Linux user #261729

BinaryFrost <binaryfrost@gmail.com> wrote:
> When I remove a pakage using 'emerge -C' why does it leave entires in
> /etc?
>
> For example I was trying to remove apache so ran 'emerge -C apache',
> but later on I've found /etc/init.d/apache2, /etc/conf.d/apache2 and
> not to mention /etc/apache2/ still exist.
>
> Any ideas?

The idea is to protect configuration files, in case you had to uninstall
and then reinstall, e.g. in order to solve a conflict where there's a
new dependency. In that case, you'd be none to happy if all your
customized configuration files were gone.

However, the implementation is ill thought out, as it leaves files that
aren't configuration files (in the /etc/X11 tree, there's even binaries
that get left behind!), plus temporary and intermediate files created by
an app (which would be recreated if installing), while zapping config
files that happen to reside elsewhere.

IMO, this should really be on a per-package basis, where the package
maintainer would designate whether a file, directory or tree was
deletable upon uninstalling, plus special commands to run when deleting
the last instance of a package (e.g. to lock /etc/passwd entries for
accounts no longer used). However, that would require that the package
maintainers actually /understood/ their packages -- a rather tall order
these days.

As Johan said, your best bet is to edit the CONFIG_PROTECT and
CONFIG_PROTECT_MASK flags, and do some manual housekeeping.

Regards,
--
*Art

Johan Lindquist wrote:
> To "unprotect" a directory (for example /etc/init.d, which you might
> wish to keep clean), add it to the CONFIG_PROTECT_MASK flag.

That's a great tip! Thanks.