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