Re: Configuration file update behaviour change options
Richard Kettlewell writes:
> Personally, I don't like the the chmod-like syntax. We aren't going
> to be using this thing as often as chmod; , so the options don't have
> to be short; but they do have to be hard to get wrong since they have
> potentially quite dramatic effects on the system. Sounds to me like
> long self-explanatory names are called for.
The problem with this approach is that if I interpret it naively you
may need several quite long options to make a fairly minor change.
Let me put forward another proposal, by way of brainstorm. This is a
kind of `verbose' chmod-a-like:
<cells> := <column-spec>
| conflict ; same as edited-new
| all ; all the settable cells
<column-spec> := edited | notedited ; changed by user ?
<row-spec> := new | notnew ; changed by maintainer ?
<action-mods> := [<action-word>] <action-mod>...
<action-mod> := +<action-word> | -<action-word>
<action-word> := prompt | install | keep
So, from my previous message
--conff n=pi becomes --conff new-notedited:prompt+install
--conff a+p becomes --conff all:+prompt
(just `--conff all:prompt' would remove the defaults, whereas
`+prompt' makes the default be what was previously automatic.)
This is still fairly hard to get right, but it's more likely to
produce a usage error rather than incorrect results.
I think this still needs more thought.
Bill Mitchell writes:
>Is it perhaps sufficient to give the package maintainer the
>ability to change these options, but not the package installer;
>putting the package maintainer in control of conffile handling
No, this is missing the point. Richard Kettlewell is right.
>If so, non-default handling behavior could be specified in the
>control file or conffiles file if different from the default
>(I'd suggest extending the conffiles syntax to cover this).
Non-default behaviour of arbitrary complexity can be achieved in the
maintainer scripts if necessary.