Re: [gentoo-user] Cleaning redundant configuration files

[David W Noon]

On Thu, 02 Jun 2011 01:10:02 +0200, Alan McKinnon wrote about Re:
[gentoo-user] Cleaning redundant configuration files:

>Apparently, though unproven, at 17:52 on Wednesday 01 June 2011, David
>W Noon did opine thusly:
>> On Wed, 01 Jun 2011 17:20:03 +0200, Alan McKinnon wrote about Re:
[snip]
>> >Your suggestion runs counter to the general philosophy that runs
>> >through Gentoo.
>>
>> In what way?  Since it would be an option, it would not diminish the
>> control the user has over the machine.
>
>If you can provide solid examples where standard Gentoo tools do this
>operation:
>
>"I don't know what this is, but I'm just going to delete/modify/change
>it anyway"

My issue is with your "I don't know what this is," application.

Portage knows exactly what a given configuration file is, as the
package still owns the file.  The way it detects that the file has been
customized is that the MD5 checksum and/or file size differ from that
stored in the package manifest.

As an example, here is the manifest for sys-apps/mlocate:

========================================================================
dir /var
dir /var/lib
dir /var/lib/mlocate
obj /var/lib/mlocate/.keep_sys-apps_mlocate-0
d41d8cd98f00b204e9800998ecf8427e 1299760691 dir /etc
obj /etc/mlocate-cron.conf 61bf658fd1bd59e3d76a0508ce6a2c18 1299760691
dir /etc/cron.daily
obj /etc/cron.daily/mlocate 8a823735ba1c795530153b697a6eb4a6 1299760691
obj /etc/updatedb.conf 3b5668efaeb3c8189f0a083c5c0b0446 1299760691
dir /usr
dir /usr/share
dir /usr/share/locale
dir /usr/share/locale/en_GB
dir /usr/share/locale/en_GB/LC_MESSAGES
obj /usr/share/locale/en_GB/LC_MESSAGES/mlocate.mo
ac21511ec0a7ee5132efdcec3bba6972 1299760690 dir /usr/share/doc
dir /usr/share/doc/mlocate-0.23.1-r1
obj /usr/share/doc/mlocate-0.23.1-r1/AUTHORS.bz2
5c58a4a7b231e958659b3484a7ffc396 1299760691
obj /usr/share/doc/mlocate-0.23.1-r1/NEWS.bz2
dc349b5ff8a89aea3240d72cd5b1f003 1299760691
obj /usr/share/doc/mlocate-0.23.1-r1/ChangeLog.bz2
79d003105968fc22b09dffbeaf9fcae1 1299760691
obj /usr/share/doc/mlocate-0.23.1-r1/README.bz2
5e6b8cb236de3297976d1a44d86a8b36 1299760691 dir /usr/share/man
dir /usr/share/man/man1 obj /usr/share/man/man1/locate.1.bz2
88c757c7fb1eb260dd60fe8499d1d645 1299760691 dir /usr/share/man/man8
obj /usr/share/man/man8/updatedb.8.bz2 6aa33ce09341bf9a8f10e3ec8fe0548b
1299760691 dir /usr/share/man/man5
obj /usr/share/man/man5/mlocate.db.5.bz2
b626526695f7b1116807c33f4a370a7e 1299760691
obj /usr/share/man/man5/updatedb.conf.5.bz2
e5c7b82b2eb7bbce7ce1ce0b49ca1afd 1299760691 dir /usr/bin
obj /usr/bin/locate c16d67deca5064ea2fec1e2bb670f75f 1299760692
obj /usr/bin/updatedb 15884d54ea11e1a00b5f640ae49e93d8 1299760692
========================================================================

[For those who don't know, this file is
named /var/db/pkg/sys-apps/mlocate/CONTENTS.  All packages have a
CONTENTS file, as that is how Portage keeps track of file ownership by
packages.]

Now, nearly everybody modifies /etc/updatedb.conf.  This does not
remove that name from mlocate's manifest.  So, Portage knows precisely
to which package the file belongs.  Hence I think your assertion of "I
don't know what this is," is specious.

If I then do "emerge -C mlocate" and delete the package, my customized
version of /etc/updatedb.conf will remain on the root partition, in
spite of the fact that it is now useless.  During that emerge
operation, Portage knows that the file belongs to the package being
removed, but because the MD5 differs from that in the manifest it does
not delete the file.  I would prefer that it did delete the file, at
least in response to a run-time option.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@××××××××.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*