| | |
| | | | |
| | | 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 |
| | |
| | | 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) |
| | | 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. |
| | | 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). |
| | | |
| | | 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 |
| | | |