[ On Friday, April 16, 1999 at 16:47:00 (-0400), Todd Vierling wrote: ]
> Subject: Re: FUBARed by overly protective check in pkg_add.....
>
> On Fri, 16 Apr 1999, Greg A. Woods wrote:
> 
> : Ideally packages like PostgreSQL would install themselves with a pathname
> : prefix that includes their current version number, just as tcl/tk....
> 
> How do you decide who gets the versioned paths and who doesn't?  More
> importantly, which pkg gets the `versionless' path?  (C.f. ssh1 vs. ssh2 and
> bin/ssh.)

Ah ha!  Yes, that's the $64 question indeed!

With PostgreSQL (and probably tcl/tk and other "languages" and
"libraries") I think it's normally safe to to make the default
"versionless" path point to the latest & greatest version installed.
(How this gets done is another $64 question!)  In theory anyone wanting
to explicitly go back to using the older release will be able to do so
by chosing the appropriate "versioned" pathname(s).  However, this gets
tricky when the application doesn't explicilty support the upgrade
process in this manner.

In the case of ssh1 and ssh2 there's not much of a problem as there's
only one really "correct" solution (i.e. ssh2 must become the default
otherwise there's no reason for upgrading).  In this case the later
version knows how to deal with connections from, and connect to, the
earlier version (if indeed your security is lax enough to permit either
of those things to happen!  ;-)

Perhaps unless the application specifically supports an upgrade process
(as in ssh2) the only automatable scheme is to install all such packages
only with "versioned" pathnames and perhaps to provide a simple script
that lets the administrator provide (and change) the default choice by
installing appropriate symlinks, etc.

However this is probably even more work, not less (i.e. when the package
fauthor doesn't support this scheme in the first place), so it's maybe
not a good option for the package system in general.

For example on software development systems where I've had to be able to
simultaneously build multiple releases of a package where each release
might depend on different releases of separately managed sub-components
(eg. third-party libraries), the best solution is to never offer a
"default" path (unless you really need it for some other product that
has only a single line of development).  I.e. each build must always
specify the exact release of each separately managed sub-component that
it uses -- no silent upgrades are permitted, especially to
legacy/bug-fix builds!

I've done similar things when migrating to newer versions of production
software too, though normally there the default is the "currently in
production" version and the new (and possibly previous) releases are
given unique pathnames (and are run on test ports, or whatever).  This
is the case where rolling the new version into production requires some
additional administrative actions *after* the install (shut down the
production software, rename and reconfigure it, rename and reconfigure
the new release, and finally restart everything).  If the upgrades
happen often enough, or if the software isn't very ammenable to renaming
its prefix (and/or components), then the renaming is not a good idea and
it's better to build and install everything with permanently unique
names.

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