changeset 46 d4d60962c33f
child 151 f9e42a3f7095
equal deleted inserted replaced
45:536ea324b223 46:d4d60962c33f
     2                 Userland Consolidation Packaging Guidelines.
     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.
    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:
    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
    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.
    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)/ variant.arch=i386
    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)
    58     Actions for editable files must include an appropriate 'preserve' attribute:
    59         file path=etc/gnu/a2ps.cfg preserve=true
    61     license actions should be placed in the canonical manifest.
    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)
    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)
    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
   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
   106     This will allow the next step to resolve all dependencies to their proper
   107     package(s).
   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.
   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
   122 Publication.
   123     Once manifest validation has occurred, the package(s) is/are finally
   124     published to the workspace package repository.
   127 # vi:set fdm=marker expandtab ts=4: