This proposal regarding action semantics was discussed at a meeting in
Menlo Park last Thursday. It's being brought to the list for any further
thoughts that people might have.
Issues addressed:
749 pkg verify fails on Windows (and user images in general)
870 redesign needed for context-sensitive actions
Proposed changes:
1. The owner and group attributes for the file and directory actions
will be made optional. By policy, they will be required for opensolaris
packages, but the code will not enforce this. If the owner and group
attributes are not present, then the ownership of the file when
installed will become whatever the operating system default is for a
file created in that directory. For a verify, if the owner and group
attributes are not present, then those attributes of the file will not
be checked.
This will require modifying the implementation of the directory and file
actions, and the pkg(5) manual page.
2. Some actions are valid only in certain contexts. For the purposes of
this proposal, a "context" is defined as an environment that effects the
semantics of an action. The known contexts are the client operating
system type, processor type, zone type (global/non-global) for Solaris,
user permissions (admin/nonadmin) and image type (full, partial, user).
The following actions have limited applicability:
driver - valid only for Solaris, full image
group - not valid on Windows, not valid for USER images
hardlink - not valid on Windows
legacy - valid only for Solaris
link - not valid on Windows
user - not valid on Windows, not valid for USER images
Regarding group and user actions for USER images, the current behavior
is to create etc/passwd and etc/group files within the image. However,
this doesn't result in a user or group actually being created. So the
proposal here is to ignore these actions for USER images.
The following changes are proposed to deal with this:
a. These limitations will be documented in pkg(5).
b. The build will be modified so that actions that are not applicable
for a platform are not included for that platform.
c. The actions.fromstr method will be modified to pass through
unrecogized actions rather than throwing an exception. This is to permit
cross-platform packaging publishing, e.g., so that a Windows-specific
package containing a Windows-specific action could be published to a
depot server running on Solaris. Also, this causes unsupported actions
to be ignored by the client.
d. Context-specific actions will be modified to include implicit
attributes that declare these limitations. For example, the driver
action will automatically include a pkg.imagetype=full attribute. The
semantics of these implicit attributes will be exactly the same as if
the attributes had been specified in the manifest. If an action in a
manifest explicitly declares an implicit attribute, the explicit
declaration will be ignored.
e. The image creation code will be modified to create filters
appropriate for the image being created. These filters will include:
pkg.platform (for the operating system)
values: sunos, linux, windows, darwin
pkg.ISA (for the instruction set architecture)
values: i386, sparc
pkg.imagetype (for the type of the image)
values: full, partial, user
f. The filter processing code will be enhanced to support a "not"
construct in an attribute. If a value is preceeded with a "!", then
that means the action is applicable when the filter does not have that
value. For example, if an action has "pkg.platform=!windows" then a
filter with pkg.platform=sunos would select the action, but
pkg.platform=windows would not.
g. An additional action, "shortcut" will be added with similar semantics
as the link action except that it produces shortcuts on Windows. It will
be Windows only
h. Once these other changes are in place, then the conditional
processing related to platforms will be removed from the user and group
actions because they will always be filtered out on Windows.
4. When the implementation for an action from one platform to another is
significantly different, then the method used in the source code for
dealing with this will be to provide an alternate file for the action.
The alternate file will be renamed during the build process. For
example, if the driver action was to be supported on Linux, then a
driver_linux.py file would be created and this would be renamed to
driver.py during the build process, replacing the one used for all other
platforms.
opensolaris -> driver.py -> driver.py
linux -> driver_linux.py -> driver.py
There are no known cases where this is necessary at this time.
Tom
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
