Mark J. Nelson writes: > > usr/src/tools/SUNWmrtools/prototype_com > > > > 47-53: what is this? > > A vestigial tail.
;-} > The SUNWmrtools package was used for sideband delivery to RE, when we > changed things they needed for cdkit. I think. > > I asked about removing it, and got mild pushback (I think from Jan, > Jerry, or both), on the supposition that leaving the skeleton in place > as a template might make it easier to deliver such a thing on short > notice, should it ever become necessary. How is that different from looking through the history and digging up the bits needed? I'm a little allergic to seeing things commented out. It's a good way to accumulate weird baggage over time, and often stuff that nobody really understands or maintains. (It's not like anything checks that the commented out bits continue to match the implementation over time.) > The two changes here (removal of prototype_sparc and commenting out > files in SUNWmrtools) were made to silence the protocmp output. The > package should never have had a prototype_sparc with ARCH=i386.i86pc, > and the binaries in question are legitimately not part of the tools > proto area anyway. So I removed the former and commented out the latter. > > I don't really care for it much; I think that "hg rm > usr/src/tools/SUNWmrtools" is probably more appropriate. But this > leaves us with a skeleton svr4 pkg, and a clean tools protocmp. OK ... > > usr/src/tools/lintdump/Makefile [...] > > 35: this should already be the default. > > Yes, but Makefile.tools overrides this to be 0555. I looked for OWNER but missed that part. > > usr/src/tools/protolist/protolist.c > > > > 59: as long as you're picking typing nits, why would we be throwing > > away things that are relevant? (Did the original author mean > > "irrelevant?") > > I'm not picky on this; I interpreted the comment as meaning that > "including '.' in the protolist would cause problems," ie "be relevant." OK. I couldn't parse it. > > usr/src/tools/scripts/nightly.sh > > > > 2219,2366: it looks to me like you might need a $TMPDIR/new_closed > > flag as well. If someone is switching from closed binaries to > > closed source, then the usr/closed directory could be pulled over in > > its entirety, and the per-changeset output would be huge. > > Ok, I had mostly thought of that as a corner case, but it doesn't sound > like an unreasonable thing to do. I've done it a couple of times, but manually. -- 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
