[augeas-devel] Enhanced inittab lens

[Matthew Palmer]

On Fri, Jun 12, 2009 at 02:53:28PM -0700, David Lutterkort wrote:
> On Fri, 2009-06-12 at 14:49 +1000, Matt Palmer wrote:
> > The existing structure of the inittab lens:
> > 1/
> > 1/id = "sa"
> > 1/runlevels = "12345"
> > 1/process = "whatever"
> > 
> > Seems a bit... perverse.  The id is guaranteed to be unique, and is a
> > fantastic way to key your records.
> > 
> > The following patch makes the inittab lens do this.  Unfortunately, the end
> > result is not backwards compatible with the current implementation, because
> > you can't have the same value in two places in the tree representation.  I
> > do believe, however, that this new tree structure is far more workable than
> > the old version.
> 
> I am really hesitant to make that change, since it will break anything
> that modifies inittab as it is right now - and the difference is roughly
> 
>         get /files/etc/inittab/*[id = 'si']/process
> vs
>      get /files/etc/inittab/si/process

I know which one *I'd* rather be typing (and reading), and I already know
XPath.  For people who don't already know that beast, it's even less
comprehensible.

> and
>      ins si after /files/etc/inittab/*[id = 'id']

Shouldn't that be something more like:

ins 100000000 after /files/etc/inittab/*[id = 'id']
set /files/etc/inittab/*[last()]/id si

Which, incidentally, isn't guaranteed to work if you've got more than
100000000 other inittab entries, and probably doesn't work anyway now I
think about it, because last() picks the last one in the tree, not the
numerically greatest (which has tripped me up previously), so it'd be:

ins 100000000 after /files/etc/inittab/*[id = 'id']
set /files/etc/inittab/100000000/id si

I don't even know if that'll work -- whereas I know for a fact that:

> vs
>         ins si after /files/etc/inittab/id

will work properly, and is fairly comprehensible.

> Does that really seem worth the breakage of every existing user of the
> inittab lens[1] ?

I'm a big fan of making things *right*.  Breaking backwards compatibility is
a pain, yes, but it's a once-off pain for the few people currently using
Augeas, that saves pain forever more for everyone who will use Augeas in the
future.  (Where "Augeas" here equals the inittab lens).

> Does anybody have any good idea on how we should
> handle such incompatible schema changes ?

It's a pity that we can't support both ways (tie a subtree label to the
value of particular node in the subtree) but that wouldn't solve larger
backwards compatibility problems.  It's something that's
going to have to be dealt with, though, otherwise lens quality is at the
mercy of the dumbest patch to ever get approved.

Seems like this would be another thing that per-lens release management
could go some way to solving.  Pre-release lenses (which haven't had
significant testing) are ones that are more likely to break backwards
compatibility.

Lens versioning is the only thing that I can think of that would really
solve the problem.  After all, any change (even one that isn't obviously
API-damaging) is a potential breakage point if someone was relying on the
broken behaviour, especially in a product like Augeas where ordering and
presence/absence of fields almost always matter, so every change to a lens
has the potential to screw someone up.  Shipping different lens versions and
allowing people to pick whichever one they want is the ultimate flexibility,
and will allow people who want to continue using the broken behaviour to do
so, while simultaneously allowing other people to use the new, less broken
behaviour.

Or we could just accept that sometimes there will be breakage, that it is
the way of software projects which are entering whole new uncharted areas
and solving previously intractable problems to sometimes need to change how
they do things, and that people should learn to read the release notes.

Incidentally, the interfaces changes that I made previously would also have
broken compatibility for anyone who was relying on it's broken behaviour...

> [1] Incidentally, there was a post on puppet-users today by somebody who
> is using the inittab lens - he'd have to rework his puppet manifest
> after the change.

Non-backwards-compatible changes are required to the augeas Puppet type
before it's anywhere close to usable, IMO.  That the inittab lens might also
change is the least of that bloke's problems.

- Matt