| 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 |
Archives