Subject: upgrading [was: Re: Sub package proposal]
To: Todd Vierling <firstname.lastname@example.org>
From: Hubert Feyrer <email@example.com>
Date: 10/22/2000 19:25:58
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 Feyrer <firstname.lastname@example.org>