>I don't know if the effort that would be required to offer this degree
>of compatability is really worth it or not.  So far we've not yet (as
>far as I can remember) heard from anyone else who runs 'ac' or similar
>on a regular basis and who uses third-party utmp/wtmp-frobbing programs
>that would be hard to update during an OS upgrade.

I run ac regularly - or rather my accounting stuff does.
Actually, I wrote our ac, so its no surprise that I use it :-)
I also have a login implementation and several other bits and pieces
that I'd have to frob to accommodate a utmp/wtmp change.

I've written utmp/wtmp frobbing code for SunOS, Solaris, HP-UX, and 
several others.  Most of whom do not even document how/what the do.

Anyway, so I probably have as much "stake" in the impact of a utmp/wtmp
change as any.  I'm also sitting here on a 1.4.2 system that still has 
binaries that date back to 386bsd days, and I'm way grateful that they
all still "just work" because I have better things to do that recompile
them - this is the 2nd or 3rd generation of this machine, and its 
still pretty slow :-)

NetBSD have traditionally done an excellent job of backwards compatability.
Only one glitch that I'm aware of - when we went from 0.9 to 1.0
there was one fcntl that missed out on a compat struct version - broke 
the _only_ piece of 3rd party commercial s/w I've ever bought :-(
and it was expensive too.

So... I'm all for backwards compatability... and I definitely don't have
time for recompiling stuff that works.  But despite all that,
I wonder whether attempting to provide compatability for old utmp files
is worth it.


--sjg