On Fri, Oct 28, 2005 at 04:20:04PM +0200, Martti Kuparinen wrote:
> 
> It seems like CHECK_FILES=yes does not understand INSTALL and
> DESINSTALL files as it insists these files should be in PLIST...
> 
> ===> Registering installation for LPRng-core-3.8.28nb1
> ===> Checking for work-directory references in LPRng-core-3.8.28nb1
> ===> Checking file-check results for LPRng-core-3.8.28nb1
> *** The PLIST does not match installed files!
> *** The following files are in /usr/pkg but not in the PLIST:
>         /usr/pkg/etc/lpd/lpd.conf
>         /usr/pkg/etc/lpd/lpd.perms
>         /usr/pkg/etc/printcap
> *** Error code 1

There are two important targets related to the "check-files" implementation
in bsd.pkg.check.mk -- check-files-pre and check-files-post.  They
are the targets run to generate a list of files on the disk before
and after we install the packages files.  Now, we try to be somewhat
smart about when we run the "check-files-post" target -- it's run just
before we run the "post-install-script" target.  This should mean that
any files created by the +INSTALL script at POST-INSTALL time should
not be picked up by the "check-files" sweep.

Most likely, what is happening in LPRng-core is that the distribution's
makefiles are copying the configuration files directly into
/usr/pkg/etc/lpd.  This would cause these files to be noted during
the run of the "check-files-post" target.  The simplest way to solve
this in packages that use GNU autoconf is to add the following to the
package Makefile:

    INSTALL_MAKE_FLAGS=	${MAKE_FLAGS} sysconfdir=${EXAMPLEDIR}

This causes the distribution's makefiles to think sysconfdir is
${EXAMPLEDIR} only during package installation, and should cause the
configuration files to be copied into ${EXAMPLDIR} instead.  This is
also simpler than patching the package to not install any configuration
files, and then having to manually do it ourselves in a post-install
target.

I'm not sure why the LPRng-core package uses it's own INSTALL and
DEINSTALL files instead of using the ones from the pkginstall framework,
even though USE_PKGINSTALL=yes in the package Makefile.  I think this
is only because this package was untouched for a very long time.

	Cheers,

	-- Johnny Lam <jlam@pkgsrc.org>