| 1 |
Apparently, though unproven, at 18:26 on Thursday 02 June 2011, David W Noon |
| 2 |
did opine thusly: |
| 3 |
|
| 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. |
| 31 |
|
| 32 |
Please look a little deeper and try to understand what I am saying, your |
| 33 |
response is bordering closely on being a strawman. |
| 34 |
|
| 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: |
| 40 |
|
| 41 |
[snip file list] |
| 42 |
|
| 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. |
| 52 |
|
| 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. |
| 56 |
|
| 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). |
| 59 |
|
| 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). |
| 63 |
|
| 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. |
| 69 |
|
| 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. |
| 74 |
|
| 75 |
Says whom? |
| 76 |
|
| 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? |
| 81 |
|
| 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. |
| 87 |
|
| 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. |
| 91 |
|
| 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? |
| 96 |
|
| 97 |
Are you really willing to take that chance? |
| 98 |
|
| 99 |
-- |
| 100 |
alan dot mckinnon at gmail dot com |
Archives