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

[David Lutterkort]

On Mon, 2012-08-13 at 11:59 +0100, Dominic Cleal wrote:
> 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?

If nobody will show up with pitchforks on my doorstep, I'd be ok with
breaking compat and using the first form that Raphael suggested. If you
commit patches for that, please make sure the commit message clearly
says that that's a compat change so I can properly point it out in the
NEWS etc.

David