46N/A Userland Consolidation Packaging Guidelines.
46N/A Each component that integrates into the Userland consolidation must have at
46N/Aleast one package manifest that describes the content to be delivered. In some
46N/Acases components *may* deliver through multiple packages. Canonical component
46N/Apackage manifests must be placed in the component's build directory. They also
46N/Amust be named *.p5m.
46N/A In order to understand what must go in the content of a package manifest,
46N/Ait's useful to have an understanding of how a canonical manifest is transformed
46N/Ainto a final manifest used for package publication. Manifest transformation
46N/Atakes the following basic path:
46N/A (.../{component}/{component}.p5m)
46N/A (.../{component}/{build-dir}/manifest-$(ARCH)-{component}.mogrified)
46N/A dependencies generated
46N/A (.../{component}/{build-dir}/manifest-$(ARCH)-{component}.depend)
46N/A dependencies resolved
46N/A (.../{component}/{build-dir}/manifest-$(ARCH)-{component}.resolved)
46N/A manifest validation
46N/A (.../{component}/{build-dir}/manifest-$(ARCH)-{component}.linted)
46N/A publication manifest
46N/A (.../{component}/{build-dir}/manifest-$(ARCH)-{component}.published)
46N/A The canonical manifest contains actions that can't otherwise be generated
46N/A automatically from the data encapsulated in the component Makefile, gate
46N/A transformations, build tree, and packaging tools. This includes actions
46N/A for license information, some path related attributes, legacy actions,
46N/A non-discoverable dependencies, user, group, driver, and others.
46N/A Actions that are associated with objects that are specific to a single
46N/A the architecture that applied to the action. Ex:
46N/A Actions for editable files must include an appropriate 'preserve' attribute:
46N/A license actions should be placed in the canonical manifest.
46N/A The canonical manifest is combined with a template manifest header at
46N/A in $(WS_TOP)/transforms, and a set of macros are combined to more complete
46N/A package manifest using pkgmogrify(1). The transforms apply default
46N/A attributes to the various actions in the canonical manifest(s). More
46N/A detail about the attributes can be found in the transform file themselves.
46N/A The macros applied at the time of mogrification are as follows:
46N/A $(IPS_COMPONENTVERSION)
46N/A $(COMPONENT_PROJECT_URL)
46N/A $(COMPONENT_ARCHIVE_URL)
46N/ADependencies Generated
46N/A The mogrified manifest and the prototype install tree are passed through
46N/A pkgdepend(1) to generate a set of dependencies for the package content.
46N/A These dependencies are only those that "pkgdepend generate" can determine
46N/A on it's own. Additional dependencies that can not be automatically
46N/A determined by pkgdepend(1) should be placed in the canonical manifest.
46N/A Staticly defined dependencies should be described in a canonical manifest
46N/A in an unresolved form (ie. the form generated by "pkgdepend generate").
46N/A This will allow the next step to resolve all dependencies to their proper
46N/ADependencies Resolved
46N/A The manifest with unresovled dependencies is passed through pkgdepend(1)
46N/A again to resolve dependencies against the package repositories. The
46N/A result is a manifest that is suitable for publication.
46N/A The resolved manifest(s) and prototype install tree are passed through
46N/A a set of validations. This includes running pkglint(1), comparing the
46N/A manifest content to the prototype install tree, and validation of the file
46N/A content of the prototype install tree. Any anomolies are reported.
46N/A Content validation is performed by extension to pkglint(1) in
46N/A Once manifest validation has occurred, the package(s)
is/are finally
46N/A published to the workspace package repository.
46N/A# vi:set fdm=marker expandtab ts=4: