If you're not interested in pkgviews, you can disregard the rest of this
mail and resume your normal mail-reading activities.

I've been thinking a lot about how to solve what I call the "module
package" problem in pkgviews.  This problem crops up one way or another
in all depoted package systems.  One of the packages in which this
problem manifests itself is the pkgsrc/security/PAM package on a pkgviews
system.

PAM looks for its authentication modules in a location defined at
compile-time.  Currently in pkgviews, this is set to
${VIEWBASE}/lib/security, which for the default view is
/usr/pkg/lib/security.  Module packages like pam-smbpass or pam-ldap
build and install into their own depot directories, and are then symlinked
into the default view, so the modules appear as
/usr/pkg/lib/security/pam_smbpass.so or /usr/pkg/lib/security/pam_ldap.so.
This allows the module packages and the PAM package to use
/usr/pkg/lib/security as the agreed-upon location for PAM authentication
modules.

This means that all of the PAM modules you have installed are found by
every version of PAM you have installed, whether or not they're
incompatible with some of those PAM versions.  Also, PAM must be added
to the default view or else it won't work, regardless of whether it's
in another view.  In practice, that means you can really only have a
single version of PAM installed and it _must_ be in the default view,
which is totally not in the spirit of pkgviews.

I'd like to change where a depoted package may be symlinked into by
allowing a module package to symlink directly into the depot directory
of the main package, .i.e. allow security/pam-smbpass to symlink its
files into security/PAM's depot directory.  This allows PAM to just look
for its modules in <PAM's depotdir>/lib/security.  Now we can allow PAM
to be removed from the default view and/or added to as many views as
we'd like and it will still work properly.  There's no artificial reliance
on the package or its modules being in the default view.  This solution
would also work for apache/ap-*, php4/php4-*, perl5/p5-*,
cyrus-sasl2/cy2-*, and any other set of modular packages which would
also suffer from the "module package" problem.

The main change involved will be to modify pkg_delete(1) to always use
pkg_view(1) to remove package instances from views, or to simply exit
and tell the user that he should execute "pkg_view delete <pkgname>" to
delete the package instance from the view.  This change is needed so
that removing the instance of the main package from a view will work
correctly since more files than the ones listed in its PLIST may have
been symlinked into the view directory due to the possible presence of
module packages.  Also, when a module package has been added to the main
package's depot directory, there should be some automatic operation to
restow the main package so that the new files appear in all of views to
which it belongs.

If a true pkg_delete(1) on package instances is disallowed as I propose
above, then we can also enhance the linkfarm(1) script to do what GNU
stow calls "tree-folding" and "tree-splitting" to be more efficient in
the actual number of symlinks used when symlinking depoted packages into
view directories.

I'll have to think a bit harder about how to get all of the details
right.  I'm just soliciting feedback on the general idea.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>