Nicolas Williams writes: > On Mon, Jun 16, 2008 at 02:04:38PM -0400, James Carlson wrote: > > (No, before anyone asks: ksh93 need not apply for the job here. It's > > not on S9, which would make the use of it non-LU-compliant.) > > I'm not entirely sure what I can rely on. The problem is that any > changes made to i.services means testing upgrade from S9 (and whoever > backports, if anyone does, would have to test upgrade from S8). Ouch.
It's a safe bet that anything in SUNWCmreq and that's been there since at least Solaris 2.6 (oldest I have easy access to -- and doesn't have mreq but does have req) and that's in common use among other package class action scripts is ok to use. nawk fits that bill. > I'd much rather do John Levon's suggestion than optimize i.services. It's an awfully trivial script. > > Until this new OpenSolaris mechanism displaces the existing Nevada, I > > don't think it would be responsible to ignore the problem. Right now, > > Indiana and IPS are "just projects," and shouldn't dictate (or negate) > > integration requirements any more or less than any other > > non-integrated projects. > > OTOH, upgrade to SXCE/SXDE/any Nevada build is simply not supported. > And likely never will be. (Technically upgrades between Nevada builds > and SX* releases are not supported either, right?) Not supported but not expected to fail or behave poorly. We've consistently treated upgrade failures in this area as _bugs_ -- ask Mary Ding if you need confirmation on that. > So how is spending a large amount of time on cutting that 1.5 minutes > down responsible, rather than irrelevant? Of course, part of the answer > may be that just because such upgrades are not supported doesn't mean > that noone does them (I do them). If writing the 15 lines that make up the guts of that script in some more efficient manner taks a "large amount of time," then I'd suggest either deferring this change until after IPS integrates or perhaps finding someone willing to do that work. > > (How you > > can claim to have TCP/IP support but lack basic functionality like > > that is a mystery to me. I guess nobody does anything like real > > networking there ...) > > Maybe everyone just hardcodes their port numbers (one has to anyways, in > case the needed entries are not in /etc/services). Maybe. > > Plus, you'd confuse the heck out of administrators. Perhaps even more > > so than we did with our "ipnodes" stuff. > > A comment in /etc/services might suffice. Then again, maybe not. Common practice is to use grep rather than getent, but I see the point. > This is different from > ipnodes, I think. The primary benefit would be that we'd commit to > shipping the IANA registrations in a non-editable file, so you could > rely on that contents, but you could still overwrite it. OTOH, yes, it > does seem a bit odd. There are three name services databases where we > could follow this tack: protocols, services and rpc. Of these only > /etc/services is often modified, I doubt anyone ever needs to modify > /etc/protocols, and we're the registry for ONC RPC programs. In terms of the familiarity bugaboo, we'd be driving in the opposite direction on that one. I get why you want to do it; that much is clear. I'm not sure about the lasting benefit. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> 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 _______________________________________________ networking-discuss mailing list [email protected]
