1 |
On Thu, 14 Sep 2006 08:51:09 +0200 Harald van Dijk <truedfx@g.o> |
2 |
wrote: |
3 |
| On Mon, Sep 11, 2006 at 11:22:11PM +0100, Ciaran McCreesh wrote: |
4 |
| > Comments both on the nature and the specifics of the specification |
5 |
| > would be welcomed. In particular, I'd like to know if people think |
6 |
| > we're mandating the appropriate degree of specificity and whether |
7 |
| > we're providing sufficient generality to avoid overly restricting |
8 |
| > innovation. |
9 |
| |
10 |
| I think this is overly restrictive, actually. It's a good idea to |
11 |
| specify which files and directories will be matched by CONFIG_PROTECT |
12 |
| and _MASK, since that's something ebuilds end up using, but it may be |
13 |
| better to leave the details on how they will be protected up to the |
14 |
| package manager (which can in turn make it configurable for the user). |
15 |
| For one example of what a package manager, if configured to do so, |
16 |
| should in my opinion be allowed to do: automatically remove unmodified |
17 |
| and abandoned configuration files on updates. (This is not the same as |
18 |
| setting CONFIG_PROTECT=-*.) For another, a package manager, if |
19 |
| configured to do so, should in my opinion be allowed to store the |
20 |
| config files on a (possibly local) cvs/svn server in addition to the |
21 |
| real filesystem, avoiding ._cfg* files altogether. Specifying how |
22 |
| they will be protected prevents things like this. |
23 |
|
24 |
Hm, the specification doesn't preclude additional functionality. It |
25 |
just describes how things should work when normal configuration |
26 |
protection is in action. |
27 |
|
28 |
-- |
29 |
Ciaran McCreesh |
30 |
Mail : ciaranm at ciaranm.org |