1 |
On Tue, Sep 12, 2006 at 12:15:34AM +0100, Ciaran McCreesh wrote: |
2 |
> On Mon, 11 Sep 2006 16:02:53 -0700 Chris White <chriswhite@g.o> |
3 |
> wrote: |
4 |
> | On Monday 11 September 2006 15:22, Ciaran McCreesh wrote: |
5 |
> | > * Otherwise, try again with ``._cfg0001_name``, then |
6 |
> | > ``._cfg0002_name`` and so on (base ten is used for the number part) |
7 |
> | > until a usable filename is found. |
8 |
> | |
9 |
> | For what purpose are the older cfg[number]_name files kept around? I |
10 |
> | ask because I would anticipate the default behavior for replacing |
11 |
> | configuration files with their pending updates to be picking the |
12 |
> | newest update. That said, the previous versions would not serve a |
13 |
> | purpose, or is there something I don't see? |
14 |
> |
15 |
> Existing tools ask the user which file they want to use when there's |
16 |
> more than one. It's possible that this is more useful behaviour, |
17 |
> especially if, say, someone is upgrading and downgrading the same |
18 |
> package repeatedly for testing purposes. |
19 |
|
20 |
Personally, think the behaviour should be that it ensures a copy of |
21 |
the file winds up config protected; in other words, if a preexisting |
22 |
copy is already sitting in the config protected file stack |
23 |
(essentially), don't see any point to adding yet another file. |
24 |
|
25 |
Renaming to max + 1, or reusing the max if the match is the max is the |
26 |
match. |
27 |
|
28 |
Pkgcore doesn't *quite* do this (reuses any match), but shifting the |
29 |
file in the 'stack' makes more sense imo. |
30 |
~harring |