Subject: Re: Upgrading vs. dependencies vs. ...
To: Hubert Feyrer <hubert.feyrer@rrzc1.rz.uni-regensburg.de>
From: Todd Vierling <tv@pobox.com>
List: tech-pkg
Date: 07/20/1998 20:59:26
On Tue, 21 Jul 1998, Hubert Feyrer wrote:

: Maybe do @unexec commands?

: (Do if we're sure shlib symlinks aren't generated using "@exec
: ln"/"@unexev rm").

Al should have already linted for shlib symlinks made via this method.  They
should all be automatic now, with symlinks added as actual file entries
during automatic shared object handling.

Of course, if a system is known to be NOPIC, there's no need to keep the old
version of dependent pkgs.  :)

: >     = 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 ...

It should keep @dirrm and @cwd, but no others, for safety's sake.

: >     = 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. 

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

Think about pkgs containing scripts that call perl or tcl or tcsh or even
gtar.  How do you distinguish between a dependency on shlibs and a
dependency on user bins?  That's why the dependency on both pkg versions:  
to cover all bases until such time that the dependent pkg is recompiled
against the new version of the dependency.

: (1) The implementation of this is roughly (sh-syntax):
  [snip]
:     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.

Possibly, but remember that we need to either produce something that won't
break 1.3's pkg_add bin, or ship a set of "replacement pkg_* tools" for
1.3.x - I prefer the latter.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)