Subject: Re: Package config/var file paths proposal
To: None <tech-pkg@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: tech-pkg
Date: 01/07/1999 18:39:43
[ On Thu, January 7, 1999 at 14:58:38 (-0800), Curt Sampson wrote: ]
> Subject: Re: Package config/var file paths proposal 
>
> If that's the case, why have any separate directories for packages
> at all? Why not just install the files in /usr/bin, etc.?

I'd *like* to be able to continue to separate pkg installs from the rest
of the system so that *I* can keep pkg stuff totally separate from
system stuff on my -current development machine(s).

For example on my new i386 development server I've got / (root) and a
full mirror /altroot (done with pax) so that I can do "make build" and
still back out by simply booting from the other spindle.  I can also
completely zap /altroot and do a "make DESTDIR=/altroot install" and see
how closely the resulting system matches my running / (root) partition
(i.e. see if new files appear or others disappear, etc.).

As a result I don't want to mix "extra" stuff in there so as to avoid
any possibility of confusion.

Instead I keep /usr/local and /usr/pkg as symlinks pointing to
directories on another filesystem.  I also share this other filesystem
(and a normally common /var filesystem and a /tmp filesystem) no matter
which spindle I boot, though this latter aspect is less important to the
scheme.  This is also why I've been using xpkgwedge on this development
server -- I don't want anything outside of /usr/src and /usr/xsrc
installed on my base OS filesystem(s), at least not on this server.

I guess I'm saying that we should continue to make it possible to have a
separate ${PREFIX} for pkg installs simply because we can.  I think it
helps me in doing systems development.  I suppose it also makes it
slightly more efficient to share /usr and a separate ${PREFIX}
directories with a different set of installed packages in each too....

I suppose once the common pkg database is available, *and* once the
system itself is installed (or at least registered) using pkgtools, and
provided there's a reasonably easy way to find all un-registered files
within a given hierarchy, then there'd be no reason for *me* to keep
third-party software packages in separate places.

BTW I've now successfully use LOCALBASE=/usr with a couple of symlinks
(/usr/etc -> ../etc and /usr/var -> ../var) to try installing pkgsrc
stuff right in with the system, and it seems to work OK.  I'm fairly
sure I'm going to begin installing production machines in this way.

If LOCALBASE were made into three variables, I think we'd be able to
have the best of all worlds, and keep everyone happy:

	LOCALBASE=	/usr/pkg
	LOCALCONF=	${LOCALBASE}/etc
	LOCALVAR=	${LOCALBASE}/var

but this would require some re-engineering of the pkgtools (I think), as
well as a major overhaul (though not necessarily a "flag day") of the
entire pkgsrc collection.

However I think that option "B" (i.e. as per the above example), along
with some way to choose the appropriate policy for pkg installs at the
time the system itself is first installed (i.e. setting /etc/mk.conf,
creating the appropriate symlinks as per my last message, etc.), would
be the simplest solution that meets the needs of everyone.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>