[ On Wed, December 16, 1998 at 12:19:11 (-0500), Todd Vierling wrote: ]
> Subject: Re: Package Paths Proposal v2
>
> On Wed, 16 Dec 1998, Curt Sampson wrote:
> 
> : > Also, please note the move from /pkg to /usr/pkg, and the reasoning I
> : > explained for this.
> : 
> : That was exactly the change I was referring to. I confess at this
> : point I don't entirely understand the reasoning. Perhaps you could
> : restate it for me?
> 
> People using the existing package system -- and more importantly, existing
> binary pkgs -- have to do Nothing to use the new system; simply adding a
> symlink at /usr/pkg (instead of letting pkg_add create the directory)
> suffices to intermix binaries.  People who don't have to mix don't change a
> thing.

Umm....  do you mean people using binary pkgs should be able to install
them in a different location simply by changing the symlink?  If so,
then I don't think that'll work for *all* packages.  It might work for
some, but if there are paths compiled into those binaries then they'll
also have to be visible through their compiled paths.  So far as I can
tell it's still not a given that all packages can be installed at a
different prefix than they were compiled for.  This should be fixed, but
it may involve quite a bit of work, in some cases, to do "right".

> : > This requires a separate scheme whereby
> : > such pkgs know how to move the system binaries out of the way no matter
> : > where the replacement ones exist on the system.
> : 
> : Why not just pkg_delete the system binaries (because you got a
> : PLIST with them when you installed) and pkg_add the new ones?
> 
> Because neither our current system nor the distrib-lists -> pkg proposal in
> the works have that fine of granularity such that you can pkg_delete
> something installed with the system distribution.  So, you move the system
> stuff out of the way so that your pkg installed stuff will not conflict.

Why not?  What exactly are you getting at here?

If I compile and install a pkgsrc package with "LOCALBASE=/", and it
replaces system files, then I will still be able to pkg_delete that
package.  I just can't restore the system files without re-installing
the entire system.  That's not necessarily a bad thing.

Iff packages are *always* installed in some private directory hierarchy,
and system versions are *always* replaced by making symlinks, then
pkg_delete could do the right thing to restore the original system files
(assuming some well meaning admin didn't "clean them up").

However it should be possible to set "LOCALBASE=/" and/or symlink
"$PREFIX -> /" and/or install a single package with "pkg_add -p /" and
forcably replace a system binary (with no chance of restoring the
original system binary).  Being able to do this is a *good* thing.

In fact if the system install was done using pkg_add then it should be
possible to use "pkg_add -p /altroot" to install a new version of the
entire system in an alternate destination directory (which perhaps could
be a separate filesystem in which case a MBR and/or boot blocks could be
installed and the new system could be booted from this new root
filesystem).  Additional new packages could be added to this filesystem,
either separate from the new system, or integrated into it, by using the
appropriate '-p' argument to pkg_add.  I.e. it should go both ways!

-- 
							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>