Brock, With this change pkgplan.preexecute runs the action.preinstall methods for the actions and prepares the package for downloading. If lines 408/409 are moved to execute, then the preinstall methods would not be called before the download, which is the intent of this change.
You are right about questioning what an action's preinstall method is allowed to do. As I understand it, the purpose is to allow a check to be made that would abort the install before it gets started. This changes is enabling that. Tom Brock Pytlik wrote: > Unless I'm confused about what pkgplan's preexecute does, I'd > reorganize the code in imageplan a bit. I'd change the function name > on line 373 to "download" or something similar, then move lines 408 > and 409 down inside execute, and change the names of the status codes > from PREEXECUTED_X to DOWNLOADED_X (or something similar). The reason > preexecute was broken out in the first place was to make sure the > cached downloads were part of the snapshot/alternative boot env. > > I believe this should be safe to do for now. My only general > hesitation is that it's not clear to me what actions' preinstall > method is allowed to do (there aren't many examples). > > Brock > > Tom Mueller (pkg-discuss) wrote: >> This review request is for a pair of issues that only show up on >> Windows due to the Windows file locking behavior. >> >> Issues: >> http://defect.opensolaris.org/bz/show_bug.cgi?id=2402 >> http://defect.opensolaris.org/bz/show_bug.cgi?id=2415 >> >> Webrev: >> http://cr.opensolaris.org/~tmueller/cr-2402,2415/ >> >> To fix 2402, a new portable.remove method was added with an >> implementation in os_windows that moves the file to the trash area >> (using the same functionality that is used during an update via the >> rename method). The file.remove method was modified to use the new >> portable.remove method. >> >> To fix 2415, a file.preinstall method was added on Windows only to >> check if a file that is being updated is in use. The method for >> checking if a file is in use is to rename it to itself (which will >> fail if and only if the file is locked). The imageplan, pkgplan, and >> filelist modules were modified so that the preinstalls for all >> actions are called before any files are downloaded, so that the >> install will fail as soon as possible. The preinstall check throws a >> RuntimeError which is already caught by client.py with a nice error >> message. >> >> This fix for 2415 is preliminary. In the long term, we'll need to >> have a method by which an update can be installed into a running user >> image and saved away without actually modifying the image. Later, and >> application reboot can invoke something that actually installs the >> update. This is the user image equivalent of the ZFS snapshot + >> reboot. This long term fix is going to take some time to develop, so >> the idea is to get this fix in to avoid installs that fail partway >> through. >> >> Thanks. >> Tom >> >> >> >> _______________________________________________ >> pkg-discuss mailing list >> [email protected] >> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss >> > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
