On 22/10/12 19:25, Dominic Cleal wrote:
On 22/10/12 09:37, Matthew Booth wrote:
I just created a bug for $SUBJECT here:
https://bugzilla.redhat.com/show_bug.cgi?id=868822
Has anyone seen this before? Looks weird.
Yes, it's quite normal. People often notice it with when they come to
add new nodes that belong in the middle of a "record", but using aug_set
causes the new node to appear at the end (e.g. setting an fstab option
causes the node to appear after passno). Use of aug_ins is needed to
specify the node position.
The order of nodes is set by the lens, which is governed by the file
format and parsing of that format. If an inittab entry could be
represented (unambiguously) as process, then action, then runlevels,
then you could also process that tree in the put direction. Since it
can't be read in that format, it can't be written that way either.
Augeas can't reorder nodes in the tree to fit the lens, so the nodes
have to be created that way.
The error message, when you add some whitespace shows the format it
expects the tree to be in, based on the lens:
/augeas/files/etc/inittab/error/message =
"Failed to match
{ /runlevels/ = /[^\\001-\\004\\n#:]*/ }
{ /action/ = /[^\\001-\\004\\n#:]*/ }
{ /process/ = /[^\\001-\\004\\n#]*/ }
{ /#comment/ = <snipped> }?
with tree
{ \"process\" = \"/sbin/mingetty tty\" }
{ \"action\" = \"respawn\" }
{ \"runlevels\" = \"2345\" }"
Thanks for the detailed explanation, Dominic.
Augeas's strictness is both its strength and its curse, and this is
another example. The problem is that augeas's domain is right there in
the name: shovelling sh*t. Sh*t isn't that strict ;) I *want* augeas to
be more DWIM, which I feel is more appropriate for the domain. I wonder
how far we can push it in that direction without completely giving up
the power of its strictness.
Take this case. Rather than fail immediately a node can't be reconciled
with the lens, we could re-order. How about this naïve algorithm
matching lens nodes to tree nodes:
If tree node fits lens
Consume both and continue
Else
If tree node is last sibling
If tree node is marked as retried
FAIL
Else
Re-order node to be first sibling
Mark node as retried
Roll back state to processing of first sibling
Retry
Else
Swap node with next sibling and retry
It's harder to reason about this behaviour, but it would eventually find
an order that fits, trying the given order first.
Too untidy?
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
_______________________________________________
augeas-devel mailing list
augeas-devel@redhat.com
https://www.redhat.com/mailman/listinfo/augeas-devel
