tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Modifications to INSTALL/DEINSTALL (mk/pkginstall)
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}).
Currently, when the INSTALL script is invoked, it does an "UNPACK"
action which unpacks several scripts into the package metadata
directory, followed by and invoking each of those scripts to do the
{PRE,POST}-INSTALL actions. This "UNPACK" action assumes the metadata
directory is mutable, which may not be true for other package formats
than the pkgsrc "pkg" format.
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.
2. Remove direct use of pkg_admin(1) and pkg_info(1) in the scripts.
I propose abstracting the information requests that require pkg_admin(1)
and pkg_info(1) into shell functions that can be defined in files under
mk/pkgformat/${PKG_FORMAT} and are pulled in as additional templates.
This allows for the scripts to be more generally usable by other package
formats and tools.
This is a precursor to my other project to improve the encapsulation of
pkgformat-specific code into mk/pkgformat.
Comments?
-- Johnny C. Lam
Home |
Main Index |
Thread Index |
Old Index