Stephen, Danek, There are several issues (870, 749, 954) that are all related to the problem of how the semantics of an action relates to the context in which it is used. For example, on Windows, what sense does the group action mean when there is no concept of a user group? And if there is no concept of user group, what does the group attribute on a file action or the middle digit in the mode attribute mean? On the surface, this issue is directly relevant to porting to other operating systems, but after a closer look, it appears that these issues impact IPS usage even on OpenSolaris. Consider the following additional examples:
- For a user image, what does the owner attribute on a file action mean when a non-root user cannot change the ownership of a file? - What does a driver action mean in the image for a zone (a partial image)? - What does the yet-to-be-defined SMF action mean for a user image? The context in which an action is evaluated would seem to be affected by the following: - operating system type - image type (full, partial, user, live/offline) - access rights of the user performing the operation - image and operation-specific filters In order to move the porting work forward, I'd like to work out a proposed solution for how action semantics could be defined given these contexts. And then, a proposal for how actions could be implemented to take the context into account. I'm starting with the following major assumptions: 1) Multi-context packages are desirable and must be supported. For example, for a Java program that runs on multiple OS platforms, it must be possible to define a single set of package actions for a package such that the package can be installed on any platform (even if the package might be hosted in separate repositories for separate platforms). Another example is a package that can be installed in either a live or an offline image, or a full or user image. 2) Some actions just do not make sense at all in some contexts. Some actions make partial sense in multiple contexts. Some actions make complete sense in all contexts. The design must deal with this. 3) Action implementations must be able to be context-dependent. The design must deal with multiple actions and multiple types of contexts, but potentially different types of contexts could be dealt with in different ways. For example, maybe operating system specific actions are implemented using subclassing, but image type differences are dealt with using if statements in the code. Is this a reasonable starting direction for attacking this problem? If there is already design work that can be leveraged for this, can you please point me to it? I've read through what is in the doc directory, particularly actions.txt. If there is someone in particular that I should work with on this, please let me know that too. Thanks. Tom _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
