On Sun, 22 Oct 2000, Todd Vierling wrote:
> One perk of this method, that I proposed a long time ago in different words,
> is that we could gain the ability to upgrade packages in-place without
> needing to upgrade dependencies recursively, or do nasty force-updates.
> 
> The most common dependency between packages are the shared
> libraries.  Provided that shlib major numbers are properly used, subpackages
> could mark which parts of a package are needed for "runtime
> dependencies" that would not conflict with other versions of the same
> package with different library majors.

Please do not forget that our current pkg system does not handle having
more than one version of a package installed. Whether that package does
conflict file-wise or not is not of question here. One thing that needs to
be done for that type of upgrading that you suggest here (which I think is
good) is to make our tools handle more than one pkg version being
installed. But ONLY for pkg versions that do not conflict file-wise,
e.g. we should not allow being two perl binaries installed - that's not
possible to be handled easily. 

What I'm having in mind is:
 * someone has a netbsd-base-1.6 package installed
 * he wants to upgrade to netbsd-base-1.7 pkg
 * all files from 1.6 are removed EXCEPT necessary
   (non-conflicting)  shared libs.
 * the 1.7 package is added, and 'pkg_info' will list both netbsd-base-1.6
   and netbsd-base-1.7 installed.   
 * If the user later decides he doesn't want/need the old libs any more, 
   he can pkg_delete the netbsd-base-1.6 package. 

Our tools (pkg_info -qL comes to mind, pkg_tarup, also pkg_delete) need to
be adjusted for this.

[Note: a different possibility in that upgrade scenario would be to merge
the remaining 1.6 libs into the new 1.7 package, but that would make
things bad to debug: the upgraded 1.7 package would have a different file
set than the freshly installed one, etc.]


 - Hubert

-- 
Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de>