[augeas-devel] Enhanced inittab lens

[Matthew Palmer]

On Sat, Jun 13, 2009 at 09:49:17PM -0700, David Lutterkort wrote:
> On Sat, 2009-06-13 at 15:38 +1000, Matthew Palmer wrote:
> > 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.

Noted.  All the docs I've seen make use of large non-zero-prefixed numbers;
as I notice them from now on, I'll do what I can to get them fixed.

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

I'll likely get a bit annoyed that it wasn't done right in the first place
(which is, let's face it, pretty much my natural state of being),
and if it's not an improvement there'll almost certainly be a grumble
generated, but I'll live with an incompatible improvement.

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

Yeah, if you make it obvious what's changed (and what people will see if
they've suffered the breakage, and what they need to do to make it right),
then it's hard for people to get *too* het up.  What *is* annoying, though,
is having things "magically" change without warning, and with no hints as to
what to do to make it all better.

As a suggestion for this one (to go in release notes or whatever):

----8<----

COMPATIBILITY CHANGE (inittab): The way in which inittab entries are indexed
has changed.  Instead of using a numeric index, the 'id' field of the entry
is now the key.  So where you previously would have accessed:

//inittab/*[id = val]/<field>

You will now use:

//inittab/val/<field>

Symptoms of the problem are that matches of [id = val] will fail, and
attempts to write a change that specifically sets //inittab/X/id will fail
with a match error ("/id/runlevels/... [you know what I'm talking about
here, David, and I don't have access to my work machine at the moment to
check exactly what error message is output]").

Rewriting your lens manipulations to use the ID in the path explicitly will
correct the problem, or as a workaround (until your lens manipulations are
rewritten) you can copy the previous version of the inittab lens to
/usr/share/augeas/lenses to restore the previous behaviour.

---->8----

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

That's an *excellent* quick workaround for breakage; I've added it to the
above change notice.

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

It's language for specifying changes and pre-requisites is very rudimentary;
the syntax is incompatible with those of augtool; and it doesn't
automatically verify if the changes specified are actually necessary, which
results in an awful lot of duplication of code.  I write complete custom types
(with an "Augeas-using type template" in the works) to make the changes I
need, rather than try to work with the augeas puppet type.

- Matt

-- 
"All I care about [a linux distro] is it detect my hardware (non-Debian
strengths), and teach me to fish instead of just giving me a smelly old fish
(most people 'xcept Debian), and I guess don't just give me a fish biology
textbook (gentoo)."		-- Tom (in d-devel)