165 manifest content to the prototype install tree, and validation of the file |
165 manifest content to the prototype install tree, and validation of the file |
166 content of the prototype install tree. Any anomalies are reported. |
166 content of the prototype install tree. Any anomalies are reported. |
167 Content validation is performed by extension to pkglint(1) in |
167 Content validation is performed by extension to pkglint(1) in |
168 $(WS_TOP)/tools/python/userland-lint |
168 $(WS_TOP)/tools/python/userland-lint |
169 |
169 |
|
170 Note that when integrating new packages, and one or more of them depends |
|
171 on or more of the others, then this may result: |
|
172 WARNING pkglint.action005.1 obsolete dependency check skipped: |
|
173 unable to find dependency (target pkg) for (source pkg) |
|
174 This means that the target package was not found in the reference repo, |
|
175 which was the source of the pkglint cache that was created when 'gmake |
|
176 setup' was run after the workspace was created; thus the warning is |
|
177 harmless and can be ignored in this circumstance. |
|
178 |
170 Publication. |
179 Publication. |
171 Once manifest validation has occurred, the package(s) is/are finally |
180 Once manifest validation has occurred, the package(s) is/are finally |
172 published to the workspace package repository. |
181 published to the workspace package repository. |
173 |
182 |
|
183 Renames |
|
184 |
|
185 Renames in IPS are tricky. We will use a case study to illustrate how |
|
186 this needs to work. |
|
187 |
|
188 All of the library/python-2/FOO modules that we had in Userland at the |
|
189 time were renamed to library/python/FOO in s12_41. This involved: |
|
190 * changing the FMRI to drop the "-2" |
|
191 * adding an optional dependency on the old name at the version and build |
|
192 in which the rename occurred; this forces the rename |
|
193 * depend type=optional fmri=library/python-2/FOO-$(PYV)@VERSION,BUILD |
|
194 where FOO is the component name (e.g., "alembic", "amqp", etc.), |
|
195 "$(PYV)" is that literal string, VERSION was the expanded value of |
|
196 COMPONENT_VERSION from each component's Makefile (e.g., "0.6.0" |
|
197 for alembic, "1.0.12" for amqp, etc.), and BUILD was set to |
|
198 "5.12-5.12.0.0.0.41.0". Note that BUILD needs to be set to |
|
199 the value of the build you are integrating into. |
|
200 * one or more new manifests (typically one for the versionless package, |
|
201 plus one for each versioned instance of the package) with actions: |
|
202 * set name=pkg.fmri value=pkg:/library/python-2/FOO@VERSION,BUILD |
|
203 * set name=pkg.renamed value=true |
|
204 * set name=org.opensolaris.consolidation value=$(CONSOLIDATION) |
|
205 * depend fmri=library/python/FOO type=require |
|
206 where FOO, VERSION and BUILD are all as above. |
|
207 |
|
208 So far, not too bad. This gets slightly more complicated when back- |
|
209 porting in that BUILD needs to be set to the back-port build (e.g., |
|
210 "5.11-0.175.3.0.0.8.0", as was the case for tkinter-27) rather than |
|
211 the S12 build. |
|
212 |
|
213 If the component is at the same version as when the rename was done, then |
|
214 that's it. But if the component has since been upgraded, then care must |
|
215 be taken to set VERSION in both places above to the value that it was in |
|
216 s12_41 when the rename was originally done. In particular, the latest |
|
217 version of a package name in an earlier release branch must not be greater |
|
218 than the latest version of that same package name in the newer release |
|
219 branch. Otherwise the audits from Release Engineering will complain and |
|
220 our gatekeeper will make you do a follow-up push to fix this. |
174 |
221 |
175 # vi:set fdm=marker expandtab ts=4: |
222 # vi:set fdm=marker expandtab ts=4: |