Re: Modifications to INSTALL/DEINSTALL (mk/pkginstall)

["Johnny C. Lam" <jlam%NetBSD.org@localhost>]

On Tue, Feb 07, 2017 at 11:33:57PM +0000, Johnny C. Lam wrote:
> I am going to modify the pkgsrc/mk/pkginstall module that generates the
> default INSTALL/DEINSTALL scripts for packages in the following ways:
> 
> 1. Change the scripts so that they can be invoked without modifying the
>    package metadata directory (${PKG_DBDIR}/${PKGNAME}).
> [snip]
> 
>    I propose that the scripts be changed so that they can be invoked
>    without the assumption of a mutable metadata directory, yet still
>    preserving their "idempotent" property of being able to invoke an
>    action multiple times yet only doing the actions once.
> 
>    There are two ways to do this change.
> 
>    The first is simply to place all of the scripts into ${PREFIX}.  For
>    example, we could place all of the +INSTALL, +DEINSTALL, +FONTS, +FILES,
>    etc., into ${PREFIX}/share/pkginstall/${PKGNAME} and simply have the
>    install and deinstall scripts for the package just invoke the scripts in
>    ${PREFIX}.  This requires a secondary change to pkg_add(1) to
>    pre-extract that directory to allow for proper PRE-INSTALL checks to
>    take place.
> 
>    The second is modify the scripts to be just be a single INSTALL and a
>    single DEINSTALL script that don't unpack anything.  This doesn't
>    require any changes to pkg_add(1) or pkg_delete(1).
> 
>    I am planning on doing the second option.

There is a third way that wiz@ asked me to look into -- we can move the
scripts in mk/pkginstall into an "install-scripts" package that is a
dependency for packages that use the pkgsrc-provided install scripts.

We can implement this third way as follows:

1. Create "install-scripts-1-1.0" with the "current" scripts.

2. Modify all packages that use mk/pkginstall to add a dependency on
   "install-scripts-1>=1.0".

3. If we make changes to the install scripts that are backwards compatible,
   then increase the minor version, e.g. "install-scripts-1-1.1".

4. If we make changes that are no longer backwards compatible, then create
   a new "install-scripts-2-2.0" package with a new major version.

   The reason for separate packages for each major version is to allow for
   multiple "install-scripts-[0-9]" packages to be installed simultaneously
   so that binary packages that require "install-scripts-1>=1.0" can be
   installed side-by-side with binary packages that require
   "install-scripts-2>=2.0".

5. Every time we tag a new quarterly release of pkgsrc, we can remove all
   but the latest "install-scripts-[0-9]" package.

The pros of having a separate install-scripts package are:

* We can explicitly version the scripts and spread bugfixes to those
  scripts to all binary packages more easily.

* It reduces the massive dupiication of shell code in ${PKG_DBDIR}.

The cons of having a separate install-scripts package are:

* Updating the installed install-scripts-1 package requires uninstalling
  all of the packages that depend on install-scripts-1 and then
  reinstalling them all afterwards.

Note that if there is a bug in the our existing mk/pkginstall scripts that
requires a PKGREVISION bump of all affected packages, then those affected
packages will still need to be rebuilt and reinstalled.

The annoyance with an install-scripts package comes when there is an
improvement that causes a minor version bump to the install-scripts-1
package -- installing the new version would still require the dependent
packages to be reinstalled even though they don't need any of the
improvements.

So, do the pros outweigh the cons?  This can easily be implemented;
otherwise, I'll continue to implement my original plan of a single
INSTALL and a single DEINSTALL script.

Regards,

-- Johnny C. Lam