Re: How do I discover the default PKG_DBDIR ?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 30 Aug 2009 14:22:14 +0200
    From:        Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
    Message-ID:  <20090830122214.GC20491%britannica.bec.de@localhost>

  | I don't see why it should be added. This is a pretty internal part of
  | the package tools you should not mess with, so unless given a good
  | reason I don't see why it should be exposed.

I don't want to mess with it, I just want to find it.   I'll give
an example below (not exactly what I'm doing, though I probably should do
this as well, but close enough - the real thing would take lots more
explanation than this message requires.)

  | pkg_install has no concept of LOCALBASE, PKG_SYSCONFDIR etc.

OK, I'm not surprised about that, and as I said, I can get those
anyway - I just wondered as pkg_install is configured ...

CONFIGURE_ARGS+=        --sysconfdir=${PKG_SYSCONFDIR:Q}

so somewhere it is getting that info, though I didn't look to see
what it is doing with it (why that config option exists).

  | This is IMO just harder to read for something that should be altered
  | only if you really know what you are doing.

It isn't a matter of altering it, it is a matter of what is a fact that
I can rely upon as being portable, and what is something that just happens
to be true for this installation, and might be some other value for other
systems - of course, it isn't just the pkg_* man pages that have this
problem, it is fairly pervasive these days, with people trying to make
the man pages more helpful, rather than correct - in the past, before
people began massaging man pages as part of the install process, it would
have just said "in a system dependent database directory" and given no
clue at all where that might be (and if you really believe this information
should be secret, and unknown to the masses, perhaps it should go back
to saying something like that?).    Even earlier (and this is still true
for many man pages in the system - perhaps the pkg_* ones, I haven't checked)
it would have just given the directory used on whatever system whoever
wrote the man page used, and simply been wrong for everyone else.  Some
man pages made it clear that the value given for whatever information it
happened to be was system dependendent, others did not.   We really should
be able to do better than that!

OK, for an example ... this is what I probably should be doing, but haven't
done yet.   Do remember that I want to produce a script that I can give
away to the world of pkgsrc users (including those on linux. solaris,
irix, ... any of those platforms which possibly might not have a /var/db
directory to use for /var/db/pkg and so which would configure it elsewhere).
I also want it to work for people who are just stubborn, and don't like
"well known" defaults for anything, and so config their pkg_tools differently,
just because they can...

I would like to be able to recover all my installed packages from backup
after a disc failure that requires reinstalling the system.

Of course, if I just do full restores, I get everything (root /usr) and
all the pkg stuff (/usr/pkg or wherever, /var/db/pkg and /var/db/*),
but my general policy is when a disaster like this happens, I might as
well take advantage of the enforced downtime to upgrade the system, as
just reinstalling NetBSD is as fast (probably even faster) than all the
work needed to manually newfs filesystems, run restore, ...

But that only gets me to a bare system - I can easily restore user files,
I know their directories - they're named in /etc/passwd that I can of course
restore from the root dump as an individual file (of course, the rest
of /etc as well, along with the merge process to combine old and new, but
I know /etc/passwd is a "constant" of unix, it is always there, from that
I can dig out home directory paths, and then I can restore those, ...

But I also want the packages back - the versions that were running, not
reinstalled newer ones that I haven't yet tested - I can find LOCALBASE
and restore that (/usr/pkg) so all the binaries, etc, come back easily
enough, but for the system to continue to be usable, I also need the
database that went with all of those installed packages - for that I
need to restore /var/db/pkg as well, and to correctly restore that, I
need to be able to find it.

Is this a good enough reason?   (I would note that I have considered
just doing "man pkg_admin | sed ..." and getting it that way, but that
seems rather convoluted for something that should be simple).

My actual script is a little different than that, in particular, issues
of how dump/restore actually work on different OS's are all irrelevant
(those aren't actually used), but the basic requirement is surprisingly like
that example.

kre