[ On Wed, December 16, 1998 at 12:00:30 (-0800), Curt Sampson wrote: ]
> Subject: Re: Package Paths Proposal v2
>
> On Wed, 16 Dec 1998, Greg A. Woods wrote:
> 
> > 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.
> 
> They will be. All packages will be compiled for either
> 
>     /pkg/etc, /pkg/var, /pkg/usr/..., etc. (my original proposal)

(which I still like best  ;-)

> or
> 
>     /etc, /var, /usr/pkg/..., etc. (Todd's updated proposal)
> 
> And the symlink will redirect things appropriately. So if a package
> were using share/foo/bar.data, it would look in /pkg/usr/share/foo/bar.data
> or /usr/pkg/share/foo/bar/.data (depending on the proposal), and
> find it.  The pkg directory may be a symlink instead, which causes
> it to eventually end up at /usr/share/foo/bar.data, if the system
> is set up to be integrated.
> 
> Does this make sense?

Yes, but it seems rather convoluted and a bit unstable.

> > 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.
> 
> They never would be. The prefix is fixed, and a symlink determines
> where the files actually end up.

But then the programs actually go through the symlink ever time they
access one of their companion files.  I think this is wrong as it means
changing the administrative link will break everything that's installed.
The programs should either use a configuration file that they're told
about on the command-line, of course, but that's a lot of work for some
packages...

The link should really only be there to help the administrator find the
packages, not the other way around.

> > ...then
> > pkg_delete could do the right thing to restore the original system files
> 
> This is not the right thing!
> 
> If sendmail was replaced due to a buffer overflow that lets users
> get root, I don't want the old sendmail reappearing, even for a
> second, during my next upgrade.

Then don't delete the replacement package -- just upgrade it.

In theory you wouldn't be firing up sendmail inbetween the pkg_delete
and the pkg_add of a secondary upgrade anyway, nor would you leave the
system in a state where ordinary users could login, so why worry about
such minor risks?

Of course if there's an option to pkg_delete that'll either do this
after the fact, or during the initial removal, then I'm happy.  (I just
want some way to restore the original system files (and their proper, if
not original, permissions) if a scheme that keeps them around is
adopted.)

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