Vasiliy wrote: > I think there are two issues two different thing we discussing here. > > 1. Non root installation > 2. Multiple instances of software installation > > Second one is much more complicated and recuire some kind of isolation > mechanism between different installation which may have concurrent, > incompatible software installed. Providing isolatin in this case brings > complexety of implementation on my opinion to the same level zones > implementation has, and zones was introduced exately for this reason - have > different installation of different software on the same machine (as Sarah > mentioned). Also it is already resolved in zones and packaging and patching > are supported on zones. > > I think we should try to address this issue using zones somehow. If we need > something lighter then fullscale zone - let think about this. But it will be > easyer to came up with some kind of lightweight zone for software domaing > then duplicates isolation on packaging/patching level. >
I'm not sure what you're suggesting as far as this proposal, but using zones or changing the zones implementation to provide an even lighter weight zone than a sparse zone, in order to allow non-root users to install mozilla or vim, still sounds like the wrong tool for the wrong job. > Also having different instances of same software may be resolved by oftware > provider by issueing different packages for different instances - for > different version of compiler different packages etc... > > The First issue - allowing customer with certain priveleges to manage certain > software is much less complicated and may have more use for customers. I > think we may spend some time discussing this. May be thread should be splited > in two. > > I think that administrator for this reason may grant some user to manage some > packages. Giving development group leader ability to install compilers, > codemanagement software etc. We have the ability to provide coarse-grained packaging management rights to users (i.e. you can manage all packages, or none). Finer-grained access control for managing individual packages sounds great, but still requires admin intervention, and the number of possible scenarios with issues would grow quickly. For example, if a patch crosses between two different sub-administrators, who is allowed to install the patch? -jhf-
