Re: db(3) removal and lastlogx

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Sun, Jul 22, 2012 at 12:45:49AM +0200, Joerg Sonnenberger wrote:
> > Well, in lieu of any supporting arguments for the migration of db to cdb
> > format, let's revert them all.
> 
> "I don't agree with your arguments, so you haven't given any." You are
> not being helpful.

I did ask a week ago (July 13th), and got no reply.  Others have asked
the same thing.  I guess we should all try to be more helpful.

I've seen the figures for raw database builds for cdb vs db-1.85, and
they are impressive.  But various databases are built at different
times - some at boot time, some when they change (like the db ones),
some at build time, like the terminfo db.

But these are not common occurrences, and the run time is swamped by
everything else happening on the machine.

You state that db recovery is problematic and may not be possible, but
we've had 20 years in the base system of db recovery - it's never been
an issue until now. cdb recovers a whole lot better? How can we tell?
It sounds like a non-problem has been solved.

When this migration first happened, it was pointed out that a
db-like interface for cdb would mean that much less would have to be
changed in order to transition from db to cdb.  That still seems
valid, and I don't recall any further discussion of this, other than
it being dismissed out of hand.  Why was that?

So, all in all, it would really help me a lot if you could tell us
what the plans are in general, rather than seeing things like this
happen in dribs and drabs, with little justification being given. 

Furthermore, if people ask about these things, it would be great to
get some constructive replies.  We all tend to get protective about
the things that we do, and that is only natural.  But the people who
work and use the software in this project are not idiots, and if
things are explained well, they will readily accept them (religious
items not withstanding).  Personally, I'm not a fan of db1 - it has no
transactions, its sync usage is weird, the use of large keys is
problematic, and the introduction of it for the cache for the package
database made the whole system brittle and difficult to use.  But I do
recognise that it's been tried and tested in the base system, for
limited things, over time - so if things are explained well enough
before starting, and real plans are in place, that can prevent a lot
of problems further down the line.

Thanks,
Alistair