In article <4471C1B8.8040207@pkgsrc.org> Johnny wrote:
: Gavan Fantom wrote:
: > Johnny C. Lam wrote:
: >> Through my investigations within pkgsrc/mk, I believe that the relevant
: >> parts of the package workflow which would be affected by this are
: >> "install-depends", "install", and "package".  As part of my project to
: >> split out "install" and "package" into separate modules, I'd like to
: >> re-implement them with the idea of extending them to initially support
: >> "pkgsrc" and "SVR4 package" formats.
: > 
: > Do you expect to be able to fully handle the install scripts and all the
: > other current magic that pkgsrc does (creating users, etc), in SVR4
: > packages?

: Yes, my approach is likely to be moving the +* scriptlets out of the 
: meta-data directory and into a separate location that is listed in the 
: PLISTs.  The INSTALL and DEINSTALL scripts would then be much simpler. 
: Most of the package systems I've seen support some sort of 
: install/deinstall hook, and it will involve a custom wrapper around the 
: existing +* scriptlets.  I believe that most of the existing 
: functionality provided by the pkginstall framework can be preserved.

  Please don't do this.  I would strongly prefer if the +* scriplets
weren't part of the individual packages at all.  One of the strengths
of pkgsrc is the declarative nature of the package Makefiles.

  I would like to see this reflected in the binary packages: The
package should state what services it needs from the package install
tools (create user foo, copy config file bar, ...) and leave the
implementation to the tools.  That way, we could fix bugs in the
implantation without requiring all packages to be rebuilt.

  Also, a fix in one of the scripts could result in a version bump of
the install tools, whereas it is impractical to bump the revision of
all packages using it.

						yours,
						dillo