[augeas-devel] Re: New example at creating a lens

[Jeff Johnson]

On Jul 15, 2009, at 2:19 PM, David Lutterkort wrote:

> On Wed, 2009-07-15 at 14:03 -0400, Jeff Johnson wrote:
>> Grr typoes: s/Not/Note/ and suffix renaming _ISNT_ very effective
>> in RPm (and likely *.augnew will have similar issues rediscovered)
>
> Agreed; I view the .augnew/.augsave stuff as a convenient safety net  
> for
> interactive use, it's not something you'd want to rely on to provide
> robustness of changes.
>

So what is the best solution?

For RPM, I'm intending to create a shadow tree, and copy/install into
the shadow tree rather than suffixing. I'll then attempt
automated checkins on the shadow tree to identify the state
machine transitions that I have to implement. Finally I will
embed subversion (or whatever VCS du jour) directly into RPM in
order to handle %config files within bare-metal empty chroot's.

This is not gonna be a fun or easy hack.

But "versioning" is perhaps easier to discuss first. Augeas (and VCS in
general) have several uses for "versioning". One use that you
mentioned is detecting incompatibilities by version++ within *.aug  
files.

However, "persistence" in a VCS requires chaining a set of patch  
transforms
sequentially, often (but not always) done with "versioning" on the  
transforms,
rather than on the lens recipe(s).

So how should Augeas (my real interest is RPM) track transforms  
"persistently"?

Note that "persistence" is a very deep and hard question, I don't
pretend to have my own answers yet.

But a "persistent" ordered sequence of patch transforms, whether using  
patch(1) or
Augeas lenses or git, sure sounds like a VCS to me. YMMV.

73 de Jeff