[augeas-devel] Enhanced inittab lens

[David Lutterkort]

On Sat, 2009-06-13 at 15:38 +1000, Matthew Palmer wrote:
> On Fri, Jun 12, 2009 at 02:53:28PM -0700, David Lutterkort wrote:
> > 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

Heh .. that's a pretty compelling argument for making the change ;)

> Which, incidentally, isn't guaranteed to work if you've got more than
> 100000000 other inittab entries

The best way to get unique labels when Augeas autgenerates numbered
labels (i.e., uses 'seq' in the lens) is to use labels that start with
'0', i.e. '01', '02' etc.

> , 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

Yeah, that's the correct one; and if you s/100000000/01/ it's guaranteed
to work.

> 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).

So, if I break your uses of Augeas with a similar cleanup in another
lens, you promise not to compain (too much) ? Facetiousness aside, I'll
merge your patch, since it does simplify the tree.

> 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.

Lens versioning though seems like it would get very messy over time -
and if we break backwards compatibility to get things right, what we
might mstly need is a way to clearly advertise breakage. You _can_ avoid
breakage by putting your favorite lenses (even ones replacing stock
lenses) into /usr/share/augeas/lenses - I recently changed the default
search path for lenses
to /usr/share/augeas/lenses:/usr/share/augeas/lenses/dist and only put
stock lenses into the latter directory.

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

Yeah, in that case the decision was easier for me though, since it was
so clearly broken.

> > [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.

What other problems do you have in mind ?

David