|
1 |
|
2 Userland Consolidation Packaging Guidelines. |
|
3 |
|
4 Each component that integrates into the Userland consolidation must have at |
|
5 least one package manifest that describes the content to be delivered. In some |
|
6 cases components *may* deliver through multiple packages. Canonical component |
|
7 package manifests must be placed in the component's build directory. They also |
|
8 must be named *.p5m. |
|
9 |
|
10 In order to understand what must go in the content of a package manifest, |
|
11 it's useful to have an understanding of how a canonical manifest is transformed |
|
12 into a final manifest used for package publication. Manifest transformation |
|
13 takes the following basic path: |
|
14 |
|
15 canonical manifest |
|
16 (.../{component}/{component}.p5m) |
|
17 | |
|
18 v |
|
19 mogrified manifest |
|
20 (.../{component}/{build-dir}/manifest-$(ARCH)-{component}.mogrified) |
|
21 | |
|
22 v |
|
23 dependencies generated |
|
24 (.../{component}/{build-dir}/manifest-$(ARCH)-{component}.depend) |
|
25 | |
|
26 v |
|
27 dependencies resolved |
|
28 (.../{component}/{build-dir}/manifest-$(ARCH)-{component}.resolved) |
|
29 | |
|
30 v |
|
31 manifest validation |
|
32 (.../{component}/{build-dir}/manifest-$(ARCH)-{component}.linted) |
|
33 | |
|
34 v |
|
35 publication manifest |
|
36 (.../{component}/{build-dir}/manifest-$(ARCH)-{component}.published) |
|
37 | |
|
38 v |
|
39 publication |
|
40 |
|
41 |
|
42 Canonical Manifest |
|
43 The canonical manifest contains actions that can't otherwise be generated |
|
44 automatically from the data encapsulated in the component Makefile, gate |
|
45 transformations, build tree, and packaging tools. This includes actions |
|
46 for license information, some path related attributes, legacy actions, |
|
47 non-discoverable dependencies, user, group, driver, and others. |
|
48 |
|
49 Actions that are associated with objects that are specific to a single |
|
50 architecture should be tagged with a 'variant.arch' attribute specific to |
|
51 the architecture that applied to the action. Ex: |
|
52 file path=/usr/lib/$(MACH64)/libx86onlybits.so variant.arch=i386 |
|
53 |
|
54 Actions that are associated with objects that are architecture dependent |
|
55 shoule be tagged with a 'variant.arch' attribute as follows: |
|
56 file path=/usr/bin/ls variant.arch=$(ARCH) |
|
57 |
|
58 Actions for editable files must include an appropriate 'preserve' attribute: |
|
59 file path=etc/gnu/a2ps.cfg preserve=true |
|
60 |
|
61 license actions should be placed in the canonical manifest. |
|
62 |
|
63 Actions that can take advantage of macros supplied at pkgmogrify time |
|
64 should do so. Ex: |
|
65 file path=/usr/bin/$(MACH64)/ztest variant.arch=$(ARCH) |
|
66 |
|
67 Mogrified Manifest |
|
68 The canonical manifest is combined with a template manifest header at |
|
69 $(WS_TOP)/transforms/manifest-metadata-template, a set of the transforms |
|
70 in $(WS_TOP)/transforms, and a set of macros are combined to more complete |
|
71 package manifest using pkgmogrify(1). The transforms apply default |
|
72 attributes to the various actions in the canonical manifest(s). More |
|
73 detail about the attributes can be found in the transform file themselves. |
|
74 The macros applied at the time of mogrification are as follows: |
|
75 $(ARCH) |
|
76 $(MACH) |
|
77 $(MACH32) |
|
78 $(MACH64) |
|
79 $(IPS_PKG_NAME) |
|
80 $(PUBLISHER) |
|
81 $(CONSOLIDATION) |
|
82 $(BUILD_VERSION) |
|
83 $(SOLARIS_VERSION) |
|
84 $(OS_VERSION) |
|
85 $(IPS_COMPONENTVERSION) |
|
86 $(COMPONENT_PROJECT_URL) |
|
87 $(COMPONENT_ARCHIVE_URL) |
|
88 |
|
89 Dependencies Generated |
|
90 The mogrified manifest and the prototype install tree are passed through |
|
91 pkgdepend(1) to generate a set of dependencies for the package content. |
|
92 These dependencies are only those that "pkgdepend generate" can determine |
|
93 on it's own. Additional dependencies that can not be automatically |
|
94 determined by pkgdepend(1) should be placed in the canonical manifest. |
|
95 Staticly defined dependencies should be described in a canonical manifest |
|
96 in an unresolved form (ie. the form generated by "pkgdepend generate"). |
|
97 Ex: |
|
98 depend fmri=__TBD pkg.debug.depend.file=etc/passwd \ |
|
99 pkg.debug.reason=usr/bin/vipw type=require |
|
100 |
|
101 depend fmri=__TBD pkg.debug.depend.file=sh \ |
|
102 pkg.debug.depend.path=usr/bin \ |
|
103 pkg.debug.depend.reason=usr/bin/psmandup \ |
|
104 pkg.debug.depend.type=script type=require |
|
105 |
|
106 This will allow the next step to resolve all dependencies to their proper |
|
107 package(s). |
|
108 |
|
109 Dependencies Resolved |
|
110 The manifest with unresovled dependencies is passed through pkgdepend(1) |
|
111 again to resolve dependencies against the package repositories. The |
|
112 result is a manifest that is suitable for publication. |
|
113 |
|
114 Manifest Validation |
|
115 The resolved manifest(s) and prototype install tree are passed through |
|
116 a set of validations. This includes running pkglint(1), comparing the |
|
117 manifest content to the prototype install tree, and validation of the file |
|
118 content of the prototype install tree. Any anomolies are reported. |
|
119 Content validation is performed by extension to pkglint(1) in |
|
120 $(WS_TOP)/tools/python/userland-lint |
|
121 |
|
122 Publication. |
|
123 Once manifest validation has occurred, the package(s) is/are finally |
|
124 published to the workspace package repository. |
|
125 |
|
126 |
|
127 # vi:set fdm=marker expandtab ts=4: |