manifest.py revision 227
# The contents of this file are subject to the terms of the # Common Development and Distribution License (the "License"). # You may not use this file except in compliance with the License. # See the License for the specific language governing permissions # and limitations under the License. # When distributing Covered Code, include this CDDL HEADER in each # If applicable, add the following below this CDDL HEADER, with the # fields enclosed by brackets "[]" replaced with your own identifying # information: Portions Copyright [yyyy] [name of copyright owner] # Copyright 2008 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # The type member is used for the ordering of actions. """A Manifest is the representation of the actions composing a specific package version on both the client and the repository. Both purposes utilize the same storage format. The serialized structure of a manifest is an unordered list of actions. The special action, "set", represents a package attribute. The reserved attribute, "fmri", represents the package and version described by this manifest. It is available as a string via the attributes dictionary, and as an FMRI object from the fmri member. The list of manifest-wide reserved attributes is base_directory Default base directory, for non-user images. isa Package is intended for a list of ISAs. platform Package is intended for a list of platforms. relocatable Suitable for User Image. All non-prefixed attributes are reserved to the framework. Third parties may prefix their attributes with a reversed domain name, domain name, or stock symbol. An example might be as an indicator that a specific package version is supported by the manifest.null is provided as the null manifest. Differences against the null manifest result in the complete set of attributes and actions of the non-null manifest, meaning that all operations can be viewed as tranitions between the manifest being installed and the manifest already present in the image (which may be the null manifest). """Return three lists of action pairs representing origin and destination actions. The first list contains the pairs representing additions, the second list contains the pairs representing updates, and the third list contains the pairs represnting removals. All three lists are in the order in which they should be executed.""" # XXX Do we need to find some way to assert that the keys are # XXX Do changed actions need to be sorted at all? This is # likely to be the largest list, so we might save significant # time by not sorting. Should we sort above? Insert into a # singlesort = lambda x: x[0] or x[1] """Where difference() returns three lists, combined_difference() returns a single list of the concatenation of th three.""" """Output expects that self is newer than other. Use of sets requires that we convert the action objects into some marshalled form, otherwise set member identities are derived from the object pointers, rather than the contents.""" """Filter out actions from the manifest based on filters.""" """Find actions in the manifest which are duplicates (i.e., represent the same object) but which are not identical (i.e., have all the same attributes).""" """Return a key on which actions can be sorted.""" """str is the text representation of the manifest""" # So we could build up here the type/key_attr dictionaries like # sdict and odict in difference() above, and have that be our # main datastore, rather than the simple list we have now. If # we do that here, we can even assert that the "same" action # can't be in a manifest twice. (The problem of having the same # action more than once in packages that can be installed # together has to be solved somewhere else, though.) "unknown action '%s'" % l.
split()[
0]
"""Return the dictionary used for searching.""" """Pickle the indices of the manifest's actions to the 'file'. """Return the value for the package attribute 'key'. If no such attribute is found, return 'default'. If multiple attributes are found, return the first."""