Subject: Re: Upgrading vs. dependencies vs. ...
To: Todd Vierling <tv@pobox.com>
From: Hubert Feyrer <hubert.feyrer@rrzc1.rz.uni-regensburg.de>
List: tech-pkg
Date: 07/21/1998 01:27:16
Good evening!
On Mon, 20 Jul 1998, Todd Vierling wrote:
> - Upgrading a pkg with the same version number (usually a bugfix or build
> fix): pkg will be deleted and replaced with the new pkg, preserving the
> +REQUIRED_BY file.
Fine. See below (1) for some implementation note.
> - Upgrading a pkg to a new version number:
> * If no '.*/lib\*\.so\.[0-9]+\.[0-9]+$' library files exist in +CONTENTS:
> = Install as with the same version number above.
> = Update dependent pkgs' @pkgdep lines to the new version.
> * If shared libraries exist:
> = Delete all files except these libraries, and ignore @dirrm errors.
Maybe do @unexec commands?
(Do if we're sure shlib symlinks aren't generated using "@exec
ln"/"@unexev rm").
> = Strip the +CONTENTS down to only the shared objects (and if on ELF,
> also the major-version-only symlink).
> = Keep the old pkg version installed, replacing the +CONTENTS file
> with one containing only the shared objects
Beware of things like @cwd which might be necessary to keep, too.
Maybe even "@exec mkdir" or @dirrm ...
> = Install the new version as well, and copy the +REQUIRED_BY file from
> the old version to the new version (both will contain the same
> dependencies).
> = Update dependent pkgs' @pkgdep lines to have dependencies on _both_
> the old and new pkg versions.
Um, I don't see the point in the last two steps noted here.
The +REQUIRED_BY contains pkgs that were installed/linked/compiled with
the old version.
New pkgs will be installed/linked/compiled with the new version.
Thus, pkgs depending on the old pkg won't need a dependency on the new
pkg, and new pkgs won't need a dependency on the old pkg.
Or am I missing something important here? (Easily possible...! X-)
> - If a new pkg version has changes (moved files, dropped binaries) that
> could be used directly by a dependent pkg, add a CONFLICTS entry. This
> can be hard to see in some programs and easier in others. Example: moving
> the Tcl "script library" directory.
Perfect! Automatically trying to determine any changes like these is
difficult, and the pkg-author doing some pkg upgrade will notice the
difference (i think :).
For the implementation ...
(1) The implementation of this is roughly (sh-syntax):
if pkg_info -qe foo-x.y ; then
mv /var/db/pkg/foo-x.y/+REQUIRED_BY tmp
pkg_delete foo-x.y
pkg_add foo-x.y / make install
mv tmp /var/db/pkg/foo-x.y/+REQUIRED_BY
fi
What bugs me a bit is that the first two lines and the last two
lines seem to be necessary to add to bsd.pkg.mk and pkg_add, creating
redundancy. Maybe this can be put into pkg_add in the form of "pre
upgrade steps" and "post upgrade steps" or something.
(At least having something like a switch to only run "post install
steps" would make sense to me so we would just run that instead of
stuffing all the commands we have in @exec commands anyways in pkg
Makefile's install-targets again.)
I'll try to find time reading pkg_* sources in the next few days/weeks,
maybe we know more about the implementation details then. The main danger
I'm seeing to arise here that we'll need a lot of functionality from both
bsd.pkg.mk and pkg_add, and having this in one central place won't hurt.
- Hubert
--
hf@42.org