manifest.py revision 429
39N/A# The contents of this file are subject to the terms of the 39N/A# Common Development and Distribution License (the "License"). 39N/A# You may not use this file except in compliance with the License. 39N/A# See the License for the specific language governing permissions 39N/A# and limitations under the License. 39N/A# When distributing Covered Code, include this CDDL HEADER in each 39N/A# If applicable, add the following below this CDDL HEADER, with the 39N/A# fields enclosed by brackets "[]" replaced with your own identifying 39N/A# information: Portions Copyright [yyyy] [name of copyright owner] 227N/A# Copyright 2008 Sun Microsystems, Inc. All rights reserved. 39N/A# Use is subject to license terms. 39N/A# The type member is used for the ordering of actions. 39N/A """A Manifest is the representation of the actions composing a specific 39N/A package version on both the client and the repository. Both purposes 39N/A utilize the same storage format. 205N/A The serialized structure of a manifest is an unordered list of actions. 205N/A The special action, "set", represents a package attribute. 39N/A The reserved attribute, "fmri", represents the package and version 39N/A described by this manifest. It is available as a string via the 39N/A attributes dictionary, and as an FMRI object from the fmri member. 39N/A The list of manifest-wide reserved attributes is 39N/A base_directory Default base directory, for non-user images. 39N/A isa Package is intended for a list of ISAs. 39N/A platform Package is intended for a list of platforms. 39N/A relocatable Suitable for User Image. 39N/A All non-prefixed attributes are reserved to the framework. Third 39N/A parties may prefix their attributes with a reversed domain name, domain 39N/A name, or stock symbol. An example might be 39N/A com.example,supported 39N/A as an indicator that a specific package version is supported by the 39N/A vendor, example.com. 48N/A manifest.null is provided as the null manifest. Differences against the 48N/A null manifest result in the complete set of attributes and actions of 48N/A the non-null manifest, meaning that all operations can be viewed as 48N/A tranitions between the manifest being installed and the manifest already 48N/A present in the image (which may be the null manifest). 203N/A """Return three lists of action pairs representing origin and 203N/A destination actions. The first list contains the pairs 203N/A representing additions, the second list contains the pairs 203N/A representing updates, and the third list contains the pairs 203N/A represnting removals. All three lists are in the order in which 203N/A they should be executed.""" 72N/A # XXX Do we need to find some way to assert that the keys are 307N/A # XXX for now, we force license actions to always be 307N/A # different to insure that existing license files for 307N/A # new versions are always installed 72N/A # XXX Do changed actions need to be sorted at all? This is 72N/A # likely to be the largest list, so we might save significant 72N/A # time by not sorting. Should we sort above? Insert into a 72N/A # singlesort = lambda x: x[0] or x[1] 203N/A """Where difference() returns three lists, combined_difference() 315N/A returns a single list of the concatenation of the three.""" 48N/A """Output expects that self is newer than other. Use of sets 48N/A requires that we convert the action objects into some marshalled 48N/A form, otherwise set member identities are derived from the 48N/A object pointers, rather than the contents.""" 342N/A """Generate actions in the manifest of type "type".""" 111N/A """Filter out actions from the manifest based on filters.""" 111N/A """Find actions in the manifest which are duplicates (i.e., 111N/A represent the same object) but which are not identical (i.e., 111N/A have all the same attributes).""" 111N/A """Return a key on which actions can be sorted.""" 39N/A """str is the text representation of the manifest""" 72N/A # sdict and odict in difference() above, and have that be our 72N/A # main datastore, rather than the simple list we have now. If 72N/A # we do that here, we can even assert that the "same" action 72N/A # can't be in a manifest twice. (The problem of having the same 72N/A # action more than once in packages that can be installed 72N/A # together has to be solved somewhere else, though.) 146N/A if not l
or l[
0] ==
"#":
144N/A """Return the dictionary used for searching.""" 429N/A # Special handling of AttributeActions is 429N/A # needed inorder to place the correct values 429N/A # into the correct output columns. This is 429N/A # the pattern of which information changes 429N/A # on an item by item basis is differs for 429N/A # The right solution is probably to reorganize 429N/A # this function and all the generate_indicies 429N/A # functions to allow the necessary flexibility. 429N/A # The value might be a list if an indexed 429N/A # action attribute is multivalued, such as 429N/A """Store the manifest contents to disk.""" 315N/A # We specifically avoid sorting manifests before writing 315N/A # them to disk-- there's really no point in doing so, since 315N/A # we'll sort actions globally during packaging operations. 257N/A """Return the value for the package attribute 'key'. If 257N/A multiple attributes exist, return the first. Raises KeyError if 257N/A the attribute is not found.""" 257N/A # This hides the fact that we had busted attribute 257N/A # actions in the manifest, but that's probably not so 296N/A """Set the value for the package attribute 'key' to 'value'."""