I'm not volunteering to write the code to do all this, yet.  With that
said....

I had some ideas about handling pkg upgrades today.  Some fall back to ideas
I had earlier, but some are new.

First, assume that there is no such thing as a "pkg upgrade" - there is only
a "pkg delete" and "pkg add".  With that assumption, pkgs can be split into
two well defined pieces - "runtime support" and "build time support" (the
latter of which may also contain applications unique to that package).

- Each pkg would have a PLIST.runtime file containing only those bits
  which should be considered part of the "runtime support".  This PLIST
  would actually provide two pkgs to the system, pkgname-x.y and
  pkgname-runtime-x.y.

- The pkgname-x.y pkg would depend unconditionally on the
  pkgname-runtime-x.y pkg, so deleting the runtime deletes the build time
  support.

- The runtime pkg would _not_ have an implicit conflict with other runtime
  support pkgs of the same name; such conflicts would have to be explicit.

- A new pkgsrc directive, RT_DEPENDS=, would provide the same facility as
  DEPENDS, but only attach a dependency to the runtime portion of a pkg.

- The pkg_* tools would be modified to allow multiple bundled binary pkgs,
  such that a build of a two-part pkg would result in one .tgz containing
  two other .tgz's (the runtime and build time pkgs).  A "make package"
  could even result in both a "combined" pkg and a "runtime only" pkg.

- The pkg_add tool would ignore already installed pkgs that are part of
  the bundle (so you can install the "combined" pkg after the "runtime only"
  pkg is installed).

- Automatic shlib handling would put the ELF symlink with only the major
  version number in the runtime pkg, and the .so without a version number
  in the build time pkg.

All of the above works as long as the major version number of all shlibs in
a pkg changes in each release.  So, to address the corner case (only a minor
version bump, no version bump at all, only some libraries in a bundle
bumped), I came up with the following, to be applied only to -runtime- pkgs:

(Assuming pkgname-runtime-x.y is an old version of a pkg, and
pkgname-runtime-x.z is a new version...)

- The automatic shlib handling would move from pkgsrc to the pkg_* tools.

- If a shared object is to be added with the same major version number as
  one which is already installed (part of pkgname-runtime-x.y), and a
  LESSER minor version, the new library is ignored (or removed after being
  untarred).

- If a shared object is to be added with the same major version number as
  one which is already installed (part of pkgname-runtime-x.y), and a
  GREATER OR EQUAL minor version:

  * The old library is deleted, its ELF major version link removed if
    necessary, and the pkgname-runtime-x.z library is installed (with ELF
    major version link).

  * All pkgs which depend on pkgname-runtime-x.y are updated to depend
    ALSO on pkgname-runtime-x.z (the old dependency is NOT removed).

  * pkgname-runtime-x.y's CONTENTS is modified to remove the old library.
    ...This can result in an empty CONTENTS because of the above rules,
    but it may be too much work to check for this case and nullify the
    dependencies.

- If a file to be replaced in a -runtime- pkg is not a shared library, it is
  treated similarly to a library upgrade.  The old file is replaced, and
  removed from the old CONTENTS; all dependent pkgs are updated to depend
  ALSO on the new pkg.

=====

Now I'm done brainstorming for the evening.  Comments?

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