[augeas-devel] var_action with multiple variables in shellvars.aug

[Dominic Cleal]

On 27/07/12 23:16, Raphaël Pinson wrote:
> In shellvars.aug, the var_action entry manages "unset" and bare "export"
> entries, such as:
> 
> unset SOMEVAR
> export SOMEVAR
> 
> It currently does not support multiple variables per entry, and maps
> them as:
> 
> { "@unset" = "SOMEVAR" }
> { "@export" = "SOMEVAR" }
> 
> We need to support multiple variables for this lens, and there are
> several solutions to implement it:

I was looking at Krb5 issues yesterday in #288 and trying to merge Pat's
patch for #274.  I think it hits the same issue where the krb5.conf
*_enctypes settings need to change from taking a single value to one or
more values.

  { "default_tkt_enctypes" = "des-cbc-crc" }

to:

  { "default_tkt_enctypes"
    { "1" = "des-cbc-crc" } }

or similar.

> * One possibility would be to map them as an array using seq:
>     { "@unset" { "1" = "SOMEVAR" } { "2" = "OTHERVAR" } }
> While this is the most obvious and cleanest option, it breaks
> compatibility with the current schema, which we want to avoid if possible;

I prefer this option, despite breaking compatibility.

> * Another possibility is to simply accept spaces in values, and map them as:
>     { "@unset" = "SOMEVAR OTHERVAR" }
> I find this quite ugly and not practical as the variables are not
> properly parsed by the lens;

Tempting, but it undermines the reason for using Augeas.

> * David also suggested the possibility of starting an array only at the
> second variable, like:
>     { "@unset" = "SOMEVAR" { "1" = "OTHERVAR" } }
> It combines the advantages of not breaking the current scheme, while
> providing an array. However, it is the only lens that would behave this
> way, and it makes it a bit clumsy I find that all variables are not
> treated the same way in the tree.

For an API user, I find this is more unpredictable, leading to more
special cases than if we broke compatibility.

> What would you choose? Would you consider it problematic to break
> compatibility in order to support this functionality?

David - what would you like to do for these?

-- 
Dominic Cleal
Red Hat Consulting
m: +44 (0)7817 878113