[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

  --conff <cells>:<action-mods>,<cells>:<action-mods>,...

  <cells>        :=   <column-spec>
                  |   <row-spec>
                  |   <column-spec>-<row-spec>
                  |   <row-spec>-<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.


Reply to: