Bart Smaalders wrote:
Tom Mueller (plain-text) wrote:
Please review these changes for fixing bug 1530.
bug: http://defect.opensolaris.org/bz/show_bug.cgi?id=1530
webrev: http://cr.opensolaris.org/~tmueller/ips-1530.1/
This change eliminates the traceback by checking to see if the owner
and group for every file and directory action exists in the
preinstall method of the actions. The fix takes into account having
user and group actions in the same install set, so the user and group
actions have to record what is going to happen in the imageplan.
Also, the preinstall actions have to be executed in the same order as
the install actions so that the user/group changes are recorded
before the file/dir actions are checked.
There are two new exceptions that inherit from ActionExecutionError,
UnknownUser and UnknownGroup.
The api version is advanced because the ImageInterface.prepare method
can now through an ActionExecutionError exception. I advanced the API
client version in the GUI code because it handles exceptions from the
prepare method the same way as it handles exceptions from
execute_plan. However, I noticed that it doesn't seem to handle
ActionExecutionErrors directly, which is really a problem unrelated
to this particular bug.
For a full image, not having a user or group is considered an error.
pkg(1) now prints a message and returns 1. However, for a user image
where the user is unable to change the ownership of a file anyway,
not having the required user/group is ignored.
Thanks.
I'm just back from Burning Man; sorry for the late comments...
I guess I'm wondering why you're making the effort to predict which
errors will occur, rather than dealing with them if and when they do.
If a user or group doesn't exist at the time of the install, many
actions may have already been installed, so the image is in a state
where a package is partially installed. This is an error case where we
can detect during the pre-install that there is going to be a problem,
so we can fail the install before it gets started.
Note that this is not necessarily a case of bad packaging. For the OS
case it is. But when installing into a user-image as a privileged user
(one that can create users), a response to this error case is that you
run useradd and then do the install again. So it is important in that
case that the image not be corrupted by a partially installed package.
It would seem far less code, and would effect performance less.
BTW, what is the performance impact of these changes?
The only significant performance impact is the extra storage in the file
and directory actions for the owner and group fields. WRT execution,
it's the same number of system calls when there isn't an error. The
actions were already sorted, so that isn't extra work.
Thanks for looking at this.
Tom
- Bart
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
