| | |
| | | (.../{component}/{build-dir}/manifest-$(MACH)-{component}.mogrified) |
| | | | |
| | | v |
| | | mangled manifest file contents |
| | | (.../{component}/{build-dir}/manifest-$(ARCH)-{component}.mangled) |
| | | | |
| | | v |
| | | dependencies generated |
| | | (.../{component}/{build-dir}/manifest-$(MACH)-{component}.depend) |
| | | | |
| | | v |
| | | dependencies resolved |
| | | (.../{component}/{build-dir}/manifest-$(MACH)-{component}.resolved) |
| | | (.../{component}/{build-dir}/manifest-$(MACH)-{component}.depend.res) |
| | | | |
| | | v |
| | | manifest validation |
| | | (.../{component}/{build-dir}/manifest-$(MACH)-{component}.linted) |
| | | (.../{component}/{build-dir}/.linted-$(MACH)) |
| | | | |
| | | v |
| | | publication manifest |
| | |
| | | automatically from the data encapsulated in the component Makefile, gate |
| | | transformations, build tree, and packaging tools. This includes actions |
| | | for license information, some path related attributes, legacy actions, |
| | | non-discoverable dependencies, user, group, driver, and others. |
| | | non-discoverable dependencies, users, groups, drivers, and others. |
| | | |
| | | Actions that are associated with objects that are specific to a single |
| | | architecture should be tagged with a 'variant.arch' attribute specific to |
| | |
| | | $(MACH) |
| | | $(MACH32) |
| | | $(MACH64) |
| | | $(IPS_PKG_NAME) |
| | | $(PUBLISHER) |
| | | $(CONSOLIDATION) |
| | | $(BUILD_VERSION) |
| | |
| | | The mogrified manifest and the prototype install tree are passed through |
| | | pkgdepend(1) to generate a set of dependencies for the package content. |
| | | These dependencies are only those that "pkgdepend generate" can determine |
| | | on it's own. Additional dependencies that can not be automatically |
| | | on its own. Additional dependencies that cannot be automatically |
| | | determined by pkgdepend(1) should be placed in the canonical manifest. |
| | | Statically defined dependencies should be described in a canonical manifest |
| | | in an unresolved form (ie. the form generated by "pkgdepend generate"). |
| | |
| | | package(s). |
| | | |
| | | Dependencies Resolved |
| | | The manifest with unresovled dependencies is passed through pkgdepend(1) |
| | | again to resolve dependencies against the package repositories. The |
| | | result is a manifest that is suitable for publication. |
| | | The manifest with unresolved dependencies is passed through pkgdepend(1) |
| | | again to resolve dependencies against the package repositories. The result |
| | | is a manifest that is suitable for publication. All these manifests are |
| | | processed together in a single step, which is more efficient than resolving |
| | | dependencies in each manifest separately. While each manifest ends up with |
| | | a .depend.res copy in the build directory, the umbrella dependency |
| | | resolution target is {build-dir}/.resolved-$(MACH). |
| | | |
| | | The resolution step is also set up to use the -e flag to pkgdepend resolve, |
| | | which limits the set of packages it looks at to resolve the dependencies it |
| | | generated in the previous step. This makes the resolution step a great deal |
| | | faster, but requires that you include a static list of these packages in |
| | | your component Makefile REQUIRED_PACKAGES macro. You can automatically |
| | | add REQURIED_PACKAGES settings for the packages used in dependency |
| | | resolution by running "gmake REQUIRED_PACKAGES". Once you have done so, |
| | | you should manually verify the Makefile additions. Having extra |
| | | packages in there is safe. |
| | | |
| | | This list is kept as the REQUIRED_PACKAGES list in your component |
| | | Makefile, which you must append to (as shared-rules introduce some |
| | | packages there themselves for your benefit). |
| | | |
| | | To test, run "gmake clean" and re-publish. |
| | | |
| | | Note that there is a possibility the list of dependencies will be different |
| | | on different architectures, so you should run this on both sparc and x86, |
| | | and combine the two lists. Please keep the lists sorted. |
| | | |
| | | Manifest Validation |
| | | The resolved manifest(s) and prototype install tree are passed through |
| | | a set of validations. This includes running pkglint(1), comparing the |
| | | manifest content to the prototype install tree, and validation of the file |
| | | content of the prototype install tree. Any anomolies are reported. |
| | | content of the prototype install tree. Any anomalies are reported. |
| | | Content validation is performed by extension to pkglint(1) in |
| | | $(WS_TOP)/tools/python/userland-lint |
| | | |