Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Cleaning redundant configuration files
Date: Thu, 02 Jun 2011 19:16:40
In Reply to: Re: [gentoo-user] Cleaning redundant configuration files by David W Noon
1 Apparently, though unproven, at 18:26 on Thursday 02 June 2011, David W Noon
2 did opine thusly:
4 > On Thu, 02 Jun 2011 01:10:02 +0200, Alan McKinnon wrote about Re:
5 >
6 > [gentoo-user] Cleaning redundant configuration files:
7 > >Apparently, though unproven, at 17:52 on Wednesday 01 June 2011, David
8 > >
9 > >W Noon did opine thusly:
10 > >> On Wed, 01 Jun 2011 17:20:03 +0200, Alan McKinnon wrote about Re:
11 > [snip]
12 >
13 > >> >Your suggestion runs counter to the general philosophy that runs
14 > >> >through Gentoo.
15 > >>
16 > >> In what way? Since it would be an option, it would not diminish the
17 > >> control the user has over the machine.
18 > >
19 > >If you can provide solid examples where standard Gentoo tools do this
20 > >operation:
21 > >
22 > >"I don't know what this is, but I'm just going to delete/modify/change
23 > >it anyway"
24 >
25 > My issue is with your "I don't know what this is," application.
26 >
27 > Portage knows exactly what a given configuration file is, as the
28 > package still owns the file. The way it detects that the file has been
29 > customized is that the MD5 checksum and/or file size differ from that
30 > stored in the package manifest.
32 Please look a little deeper and try to understand what I am saying, your
33 response is bordering closely on being a strawman.
35 When I used the word "this", I meant the file itself, it's contents and all
36 known metadata about the file. Which is a lot more information than the mere
37 existence of the file itself.
38 >
39 > As an example, here is the manifest for sys-apps/mlocate:
41 [snip file list]
43 > [For those who don't know, this file is
44 > named /var/db/pkg/sys-apps/mlocate/CONTENTS. All packages have a
45 > CONTENTS file, as that is how Portage keeps track of file ownership by
46 > packages.]
47 >
48 > Now, nearly everybody modifies /etc/updatedb.conf. This does not
49 > remove that name from mlocate's manifest. So, Portage knows precisely
50 > to which package the file belongs. Hence I think your assertion of "I
51 > don't know what this is," is specious.
53 Of course portage knows *what* the file is, it recorded the fact that it
54 installed the file. It could even know what the *changed content* of the file
55 is, that is mere data.
57 What it doesn't know is what the changed content means, because that is
58 information, not data, and portage is software (by definition it is stupid).
60 With an unmerge, portage is confronted with a changed file. It has no idea
61 what information the changes mean, not even differences consisting only of
62 whitespace (some config files are sensitive to whitespace).
64 Realize that a deleted file is gone, all information in it is removed and in
65 all likelihood cannot be retrieved (devs cannot assume that users are backing
66 up files, and it has never been a documented requirement anyway to do so). So
67 even in your example, portage really does not know what "this" is, and does
68 not delete it.
70 >
71 > If I then do "emerge -C mlocate" and delete the package, my customized
72 > version of /etc/updatedb.conf will remain on the root partition, in
73 > spite of the fact that it is now useless.
75 Says whom?
77 Why do you assume it is useless? It may well be you on your machine for the
78 next 5 minutes as the code that uses it is missing, but is it always going to
79 be useless? Can you guarantee that for all users and all instances for ever
80 and ever?
82 > During that emerge
83 > operation, Portage knows that the file belongs to the package being
84 > removed, but because the MD5 differs from that in the manifest it does
85 > not delete the file. I would prefer that it did delete the file, at
86 > least in response to a run-time option.
88 All that portage knows is that the package is being unmerged, it does not know
89 why - again, that is information and you have no way to tell portage *why* you
90 want the package unmerged, only *that* you do.
92 Your last sentence implies you'd prefer it if portage deleted the file by
93 default, but would be happy to have it done as an option. Do you comprehend
94 how dangerous that is? Do you realise how easy it is to, for example, unmerge
95 a package to resolve blockers and forget that portage will nuke your configs?
97 Are you really willing to take that chance?
99 --
100 alan dot mckinnon at gmail dot com