| 1 |
On Wed, 13 Sep 2006 19:47:12 +0200, |
| 2 |
Benno Schulenberg <benno.schulenberg@×××××.com> wrote: |
| 3 |
|
| 4 |
> I would much prefer new files to be treated as if replacing an |
| 5 |
> existing zero length file. |
| 6 |
... |
| 7 |
> it should be up to tools like etc-update to (configurably) automerge |
| 8 |
> new files |
| 9 |
|
| 10 |
A quick look through my CONFIG_PROTECTed directories shows that, on a |
| 11 |
total of ~1000 config files installed by ebuilds, only ~60 may have |
| 12 |
affected my system when they were new and have been unconditionnaly |
| 13 |
installed. With such a false-positive rate, i would probably have soon |
| 14 |
disabled the etc-update paranoid mode you propose, and i think most |
| 15 |
users would have done the same. |
| 16 |
|
| 17 |
I think that protection against harmfull new config files should be |
| 18 |
selective to be useful. It should only affect directories from which |
| 19 |
files are blindly sourced by some services you are already running. |
| 20 |
There, and only there¹, new config files are unexpected change of your |
| 21 |
existing configuration, and thus lead to unexpected behaviors. |
| 22 |
|
| 23 |
¹ Well, ok, that's not exactly true. There is also the case of config |
| 24 |
files being moved (a program expecting /etc/foo.conf in one version, |
| 25 |
and /etc/foo/foo.conf in the later), things like that. But imho, in |
| 26 |
such cases, documentation (postinst messages, or GLEP 42) is enough, |
| 27 |
whereas an anti-new-files-protection wouldn't really help. |
| 28 |
|
| 29 |
The directories i'm thinking of are all this /etc/*.d/: "acpi.d", |
| 30 |
"logrotate.d", "pam.d", etc. There, adding a new file is really |
| 31 |
just like appending a new chunk to an existing config file. |
| 32 |
|
| 33 |
Implementation of a special anti-new-file-protection for this critical |
| 34 |
directories could be done in at least two ways: |
| 35 |
- a global NEW_CONFIG_PROTECT variable (but i don't think it's would be |
| 36 |
a good idea, too hard to maintain given the number of packages / devs |
| 37 |
which would have a path to add to the list), |
| 38 |
- an ebuild-specific variable, which would be taken into account by the |
| 39 |
contents merging function of the package manager (sure, this variable |
| 40 |
should be accessible through aux_get() or alike, ie. not bash-level |
| 41 |
only, but part of the ebuild metadatas). |
| 42 |
|
| 43 |
|
| 44 |
But anyway, sorry for the off-topic Ciaran, i realize that this |
| 45 |
discussion is far from being comments on the specs you've written. |
| 46 |
|
| 47 |
-- |
| 48 |
TGL. |
| 49 |
-- |
| 50 |
gentoo-dev@g.o mailing list |
Archives