James Carlson wrote: > Darren J Moffat writes: >> James Carlson wrote: >>> I think it's a bit of teak polishing. Either will work fine, neither >>> appears to me to have architectural significance, and if the project >>> and/or consolidation team have a preference, go for that. >> I think this does have architectural significance which is why I brought >> it up. How something is packaged up and split across multiple packages >> is something we normally expect to review in ARC, > > In general, agree. > >> particularly when the >> reason for the split is to support zones and diskless clients that >> require separate root and usr packages (in the SRV4 package model but >> not with IPS). > > Also, in general, agree. Just not for this case. > >> As proposed with a root package this case is exposing, as a package >> name, something that is essentially an implementation issue of RBAC and >> our current requirement to have root and usr packages separate. This >> seems a waste of a package unless there will ever be anything else >> delivered in a root package by ngrep. > > Actually, I think that's directly contradicted by your previous > assertions. > > Creating a separate tiny root package allows the owner of a system > with writable RBAC files but without a writable '/usr' to install the > necessary bits to make this feature work. If it's done as you're > suggesting, as a single 'usr' type package with a postinstall, then > the owner of such a machine simply cannot install the necessary RBAC > bits, except by hand, as the 'usr' package is inapplicable.
I never suggested that it be done in a usr package because I know that will break sparse root zones. What I suggested is that the exec_attr entry be intgrated into the master exec_attr file in ON $SRC/lib/libsecdb/exec_attr.txt. That file is delivered from an ON root package. -- Darren J Moffat
