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. The fact that RBAC control files are in the root file system and that this feature comes with RBAC bits as part of the packaged information seems to argue to me that (at least under the dying svr4 system) it ought to have a separate package for those bits, no matter how slight. However, I also don't think it matters terribly much. > Like it or not package names are interfaces. I wasn't disputing that. Only that for this particular case minimizing the number of packages seems like teak polishing. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
