On Fri, 29 Oct 2004, Rhialto wrote:

> > What does pkg_hack do that requires generating the PLIST before install
> > time?  If this is such a bother, why not try using pkgviews?[*]
>
> I suppose needs it because it compares PLIST of the old installed
> version and the one that's about to be installed.  pkg_hack is clever:
> if the new version installs a shared lib with the same major number, the
> new package simply replaces the old one.  Otherwise, the old shared
> library is moved over to a new package, including all its dependency
> information. This way only the runtime files of the package remain, any
> later development will happen with the new package.

Sounds to me like the appropriate thing for pkg_hack to do would be the
following, which would be more extensible in the face of future dynamic
PLIST actions:

1. move the shlibs of the package to replace out of the pkg's +CONTENTS,
   the pkgdb, and the filesystem, into a temporary staging area;

2. remove the package with temporary files tracking the dangling dependents
   (a la "make replace", which I would presume pkg_hack already does);

3. install the new version of the package;

4. create the special runtime version of the old package if any major
   numbers were bumped, moving the appropriate files back from the temporary
   staging area to the filesystem;

5. reattach the dangling dependencies (to both packages, if the old runtime
   version is generated after all; this, I also presume, already happens in
   pkg_hack today).

This scheme still has the same effect, but allows the new version of the
package to be properly installed and registered before doing the special
runtime frobbing.  So any dynamic PLIST generation is guaranteed to have a
chance to run (and most importantly, won't "accidentally" pick up files from
old versions of the package).

Yes, this means that the old runtime libraries will be "missing" for the
duration of the install, but so would any libraries whose major did not
change, or any non-library support files, which are thus being replaced by
the new pkg version.  So in all, I think this gives you what you want.

Of course, to help out with implementing this sort of thing, perhaps
pkg_hack should itself be in pkgsrc under pkgtools/.  8-)

> And pkg_views also cannot replace a package in-place if there is a
> critical bugfix,

Yep, I forgot that this happens to be one of my main gripes about it.

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>