Hi, Sarah Jelinek wrote: >> Users will install packages and patches using similar interfaces >> as the root user. The default install locations will be relative >> to $HOME. Package objects will all be owned by the invoking >> user. >> File locking semantics will be unchanged from the root user's >> usage. Scripts will be run as the invoking user. >> >> > So, if a postinstall script requires changing something in the system > that the user installing the pkg doesn't have the privs to do, what > happens? Is the pkg partially installed? I would assume that having to > be root as we have to today elimates this issue since the postinstall > scripts should be able to run without failure, barring a missing file, > or conf error or something. Is it a valid concern that the scripts > associated with a pkg might not be suitable for a user to run even if > installing the core pkg is? How do we ensure this is not an issue?
Well for patches I would imagine that this will result with the patch creators needing to be aware of exactly how everything works and writing the script to take the scenarios into account. Patch creators already need to take $ROOTDIR for live upgrade and diskless client into account, plus they need to think about whether they might be installing into a sparse or full zone. This proposal would likely introduce further complexity here. Ideally as much of this work would be pushed back to the utilities themselves since thats less risky than having someone write a script in a patch or package. Ensuring that this is not an issue at the moment is handled by a test team installing and backing out patches on different scenarios and not releasing once that fail. I guess we'll have to create some new tests for this proposal! There may be packages and patches that just can not be applied to these domains, they'll have to be flagged as such I'd imagine, and the tools refuse to install them. Cheers, ~Albert -- Albert White - Patch System Test - Sun Ireland albert.white at sun.com http://blogs.sun.com/albertw
