Subject: Re: /var/db/pkg [was Re: AFS/arla]
To: None <azcb0@amdahl.com, tech-pkg@netbsd.org>
From: Hubert Feyrer <hubert.feyrer@rz.uni-regensburg.de>
List: tech-pkg
Date: 09/23/1998 11:29:19
In article <m0zK46q-0000YIC@juno.ccc.amdahl.com> you wrote:
> Actually, things are a bit more complicated than this - the pkg_*
> tools need to be taught which database to query/update etc
> 
> Notwithstanding this, I have an xfer.sh script which moves all the
> /var/db/pkg/* directories to ${LOCALBASE}/etc/pkg,
> ${CROSSBASE}/etc/pkg or ${X11BASE}/etc/pkg, depending upon the prefix
> with which the package was built.  (The cases where we modify "system"
> binaries do not count at the moment, as we do not register those
> packages to avoid de-installation of the same packages, which would
> potentially leave people without certain system binaries).
> 
> I also have some mods in the pipeline to the pkg_install tools to use
> the new prefices.
> 
> These mods all depend upon a single /etc/mk.conf variable,
> PREFIX_PKG_DBDIR, which is a boolean.
> 
> These are not ready for primetime yet - but they will be coming soon,
> most people I've talked to seem to be in agreement that this is a good
> thing.  Also, I am unwilling to modify the pkg_install tools whilst we
> have a mini-freeze in pkgsrc - one thing at a time, same as always.

Hum... having hacked pkg_* heavily last weekend, I see this as a major
can of worms, thinking of dependencies for which you'd have to know where
a pkg was installed so you can actually register any dependencies:

Our jpeg package lives in LOCALBASE, now if you install a binary pkg that
just has "@pkgdep jpeg-*" this will have to know to register itself in 
$LOCALBASE/var/db/pkg/jpeg-foo, regardless of the fact where the pkg to
install actually gets. *yuck* 8-)

To get around this, you also have to make pkg_* understand /etc/mk.conf
(or whatever the user has set $MAKECONF set to)... hairy!

If someone wants my opinion, i'd 1. not split it (as you'd have to know
where a depending pkg was installed, which we don't) and 2. not move it 
into any of LOCALBASE, ... (as you'd have to figure out where LOCALBASE
is after all - it's set to /usr/local on some of my systems).

Just another DM -,02. :)


 - Hubert

-- 
Hubert Feyrer <hubert.feyrer@rz.uni-regensburg.de>